Policy-Based Application Management

ABSTRACT

Improved techniques for managing enterprise applications on mobile devices are described herein. Each enterprise mobile application running on the mobile device has an associated policy through which it interacts with its environment. The policy selectively blocks or allows activities involving the enterprise application in accordance with rules established by the enterprise. Together, the enterprise applications running on the mobile device form a set of managed applications. Managed applications are typically allowed to exchange data with other managed applications, but are blocked from exchanging data with other applications, such as the user&#39;s own personal applications. Policies may be defined to manage data sharing, mobile resource management, application specific information, networking and data access solutions, device cloud and transfer, dual mode application software, enterprise app store access, and virtualized application and resources, among other things.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 14/340,096,filed Jul. 24, 2014, entitled “Policy-Based Application Management,”which is a continuation of application Ser. No. 14/043,902, filed Oct.2, 2013, entitled “Policy Based Application Management,” which in turnclaims priority to: provisional application 61/861,736, filed Aug. 2,2013, entitled “Policy-Based Application Management”; provisionalapplication 61/806,577, filed Mar. 29, 2013, and entitled “Systems andMethods for Enterprise Mobility Management”; provisional application61/714,469, filed Oct. 16, 2012, entitled “Policy-Based Control of aManaged Application Derived from an Unmanaged Application”; provisionalapplication 61/713,762, filed Oct. 15, 2012, entitled “Conveying DataBetween Secure Applications Running on an Electronic Mobile Device”;provisional application 61/713,718, filed Oct. 15, 2012, entitled“Secure Data Sharing Among Managed Applications”; provisionalapplication 61/713,763, filed Oct. 15, 2012, entitled “Per-ApplicationPolicy Controlled Access to Computerized Resources”; provisionalapplication 61/714,293, filed Oct. 16, 2012, entitled “ManagingEncrypted File Vaults for Managed Applications on Unmanaged MobileDevice”; non-provisional application Ser. No. 13/886,889, filed May 3,2013, entitled “Application with Multiple Operation Modes”; andnon-provisional application Ser. No. 13/886,765, filed May 3, 2013,entitled “Mobile Device Locking with Context.” Each of theaforementioned application(s) is herein incorporated by reference in itsentirety for all purposes.

This application is related by subject matter to and incorporates byreference in their entirety non-provisional application Ser. No.13/649,076, filed Oct. 10, 2012, entitled “Gateway for ControllingMobile Device Access to Enterprise Resources” (which in turn claimspriority to provisional application 61/546,021, filed Oct. 11, 2011,entitled “Systems and Methods for Management of Enterprise MobileDevices”; provisional application 61/546,922, filed Oct. 13, 2011,entitled “Systems and Methods for Management of Enterprise MobileDevices”; and provisional application 61/649,134, filed May 18, 2012,entitled “Mobile Device Management and Security”; and provisionalapplication 61/702,671, filed Sep. 18, 2012, entitled “Mobile DeviceManagement and Security”); provisional application 61/713,554, filedOct. 14, 2012, entitled “Automated Meeting Room”; provisionalapplication 61/712,948, filed Oct. 12, 2012, entitled “FrictionlessDistributive Collaborative Work Across Time and Space”; provisionalapplication 61/712,953, filed Oct. 12, 2012, entitled “Mobile Work andMicro Work Using an Activity Interface”; provisional application61/712,956, filed Oct. 12, 2012, entitled “Multi-Device Interaction”;and provisional application 61/712,962, filed Oct. 12, 2012, entitled“Orchestration Framework for Connected Devices.”

FIELD

Aspects described herein generally relate to mobile computing devices.More specifically, aspects described herein relate to techniques forimposing control over managed applications executing on mobile computingdevices.

BACKGROUND

Some enterprises (e.g., corporations, partnerships, governments,academic institutions, other organizations, etc.) maintain enterprisecomputer networks that allow enterprise users, such as employees, accessto enterprise resources, such as hardware and software applications foremail, customer relationship management (CRM), document management,enterprise resource planning (ERP), and the like, as well as other datacontrolled by the enterprise. Enterprises sometimes allow remote access,such as when enterprise users are not in the enterprise network. Also,some enterprises allow users to access the enterprise network via mobiledevices, such as smartphones, tablet computers, PDAs (personal digitalassistant), and the like. Enterprises typically deploy enterprisemobility management (EMM) solutions to assist in the management andcontrol of remote access to enterprise resources. EMM solutions havetraditionally taken the approach of managing entire mobile devicesthrough what are known as mobile device management (MDM) approaches. Inpreexisting EMM solutions, enterprises typically issue mobile devices toemployees, which are intended exclusively for business use, and theenterprise maintains control over the mobile devices and all of itsapplications and data. A recent trend is to allow employees to use theirown mobile device(s) for work purposes (a scenario known as BYOD—bringyour own device). However, BYOD scenarios pose inherent security risks,because there is neither uniform nor universal control over each device.

SUMMARY

The following presents a simplified summary of various aspects describedherein. This summary is not an extensive overview, and is not intendedto identify key or critical elements or to delineate the scope of theclaims. The following summary merely presents some concepts in asimplified form as an introductory prelude to the more detaileddescription provided below.

To overcome limitations in the prior art described above, and toovercome other limitations that will be apparent upon reading andunderstanding the present specification, aspects described herein aredirected towards mobile applications operating under the control of oneor more independent policy files defining one or more security, featureand/or resource limitations. Each application may execute in accordancewith its corresponding set of policy files, optionally received separatefrom the application and which define one or more security parameters,features, resource restrictions, and/or other access controls that areenforced by a mobile device management system when that application isexecuting on the device. By operating in accordance with its respectivepolicy file(s), each application may be allowed or restricted fromcommunications with one or more other applications and/or resources.Policy files may define acceptable behavior, e.g., based on usercredentials, user role, geographic location, network location, locationtypes, enterprise mobile management (EMM) information, and/or any otherinformation accessible or determinable by the operating device.

These and additional aspects will be appreciated with the benefit of thedisclosures discussed in further detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of aspects described herein and theadvantages thereof may be acquired by referring to the followingdescription in consideration of the accompanying drawings, in which likereference numbers indicate like features, and wherein:

FIG. 1 depicts an illustrative computer system architecture that may beused in accordance with one or more illustrative aspects describedherein.

FIG. 2 depicts an illustrative cloud-based system architecture that maybe used in accordance with one or more illustrative aspects describedherein.

FIG. 3 depicts an illustrative enterprise mobility management system.

FIG. 4 depicts another illustrative enterprise mobility managementsystem.

FIG. 5 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 6 depicts a device according to illustrative aspects describedherein.

FIG. 7 depicts a data flow according to illustrative aspects describedherein.

FIG. 8 depicts a system architecture according to illustrative aspectsdescribed herein.

FIG. 9 depicts a system architecture according to illustrative aspectsdescribed herein.

FIG. 10 depicts a system architecture according to illustrative aspectsdescribed herein.

FIG. 11 depicts a system architecture according to illustrative aspectsdescribed herein.

FIG. 12 depicts a system architecture according to illustrative aspectsdescribed herein.

FIG. 13 depicts a system architecture according to illustrative aspectsdescribed herein.

FIG. 14 depicts an illustrative method for performing policy based appmanagement according to illustrative aspects described herein.

FIG. 15 depicts an illustrative method for performing policy based appmanagement according to illustrative aspects described herein.

FIG. 16 depicts a device according to illustrative aspects describedherein.

FIG. 17 depicts a device according to illustrative aspects describedherein.

FIG. 18 depicts a device according to illustrative aspects describedherein.

FIG. 19 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 20 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 21 depicts a system according to illustrative aspects describedherein.

FIG. 22 depicts a device according to illustrative aspects describedherein.

FIG. 23 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 24 depicts a device according to illustrative aspects describedherein.

FIG. 25 depicts a system according to illustrative aspects describedherein.

FIG. 26 depicts a system according to illustrative aspects describedherein.

FIG. 27 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 28 depicts a system according to illustrative aspects describedherein.

FIGS. 29A and 29B depict systems according to illustrative aspectsdescribed herein.

FIG. 30 depicts an illustrative method for performing policy based appmanagement according to illustrative aspects described herein.

FIG. 31 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 32 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 33 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 34 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 35 depicts a system according to illustrative aspects describedherein.

FIG. 36 depicts a device according to illustrative aspects describedherein.

FIG. 37 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 38 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 39 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 40 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 41 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 42 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 43 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 44 depicts an illustrative method for performing policy based appmanagement according to illustrative aspects described herein.

FIG. 45 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 46 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 47 depicts a process flow according to illustrative aspectsdescribed herein.

FIG. 48 depicts a process flow according to illustrative aspectsdescribed herein.

FIGS. 49-56 depict illustrative methods for performing policy based appmanagement according to illustrative aspects described herein.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference ismade to the accompanying drawings identified above and which form a parthereof, and in which is shown by way of illustration various embodimentsin which aspects described herein may be practiced. It is to beunderstood that other embodiments may be utilized and structural andfunctional modifications may be made without departing from the scopedescribed herein. Various aspects are capable of other embodiments andof being practiced or being carried out in various different ways.

1. INTRODUCTION

As a general introduction to the subject matter described in more detailbelow, aspects described herein are directed towards controlling remoteaccess to resources at an enterprise computing system using managedmobile applications at mobile computing devices. An access manager mayperform a validation process that determines whether a mobileapplication requesting access to enterprise resources has accuratelyidentified itself and has not been subsequently altered afterinstallation at the mobile computing device. In this way, the accessmanager may ensure the mobile application requesting access to theenterprise resource can be trusted and is not attempting to circumventthe security mechanisms used to protect those enterprise resources. As aresult, individuals associated with the enterprise may advantageouslyutilize enterprise resources at their personal mobile devices.

It is to be understood that the phraseology and terminology used hereinare for the purpose of description and should not be regarded aslimiting. Rather, the phrases and terms used herein are to be giventheir broadest interpretation and meaning. The use of “including” and“comprising” and variations thereof is meant to encompass the itemslisted thereafter and equivalents thereof as well as additional itemsand equivalents thereof. The use of the terms “mounted,” “connected,”“coupled,” “positioned,” “engaged” and similar terms, is meant toinclude both direct and indirect mounting, connecting, coupling,positioning and engaging.

2. COMPUTING ARCHITECTURE

Computer software, hardware, and networks may be utilized in a varietyof different system environments, including standalone, networked,remote-access (aka, remote desktop), virtualized, and/or cloud-basedenvironments, among others. FIG. 1 illustrates one example of a systemarchitecture and data processing device that may be used to implementone or more illustrative aspects described herein in a standalone and/ornetworked environment. Various network nodes 103, 105, 107, and 109 maybe interconnected via a wide area network (WAN) 101, such as theInternet. Other networks may also or alternatively be used, includingprivate intranets, corporate networks, local area networks (LANs),metropolitan area networks (MAN), wireless networks, personal networks(PAN), and the like. Network 101 is for illustration purposes and may bereplaced with fewer or additional computer networks. A LAN may have oneor more of any known LAN topology and may use one or more of a varietyof different protocols, such as Ethernet. Devices 103, 105, 107, 109 andother devices (not shown) may be connected to one or more of thenetworks via twisted pair wires, coaxial cable, fiber optics, radiowaves or other communication media.

The term “network” as used herein and depicted in the drawings refersnot only to systems in which remote storage devices are coupled togethervia one or more communication paths, but also to stand-alone devicesthat may be coupled, from time to time, to such systems that havestorage capability. Consequently, the term “network” includes not only a“physical network” but also a “content network,” which is comprised ofthe data—attributable to a single entity—which resides across allphysical networks.

The components may include data server 103, web server 105, and clientcomputers 107, 109. Data server 103 provides overall access, control andadministration of databases and control software for performing one ormore illustrative aspects describe herein. Data server 103 may beconnected to web server 105 through which users interact with and obtaindata as requested. Alternatively, data server 103 may act as a webserver itself and be directly connected to the Internet. Data server 103may be connected to web server 105 through the network 101 (e.g., theInternet), via direct or indirect connection, or via some other network.Users may interact with the data server 103 using remote computers 107,109, e.g., using a web browser to connect to the data server 103 via oneor more externally exposed web sites hosted by web server 105. Clientcomputers 107, 109 may be used in concert with data server 103 to accessdata stored therein, or may be used for other purposes. For example,from client device 107 a user may access web server 105 using anInternet browser, as is known in the art, or by executing a softwareapplication that communicates with web server 105 and/or data server 103over a computer network (such as the Internet).

Servers and applications may be combined on the same physical machines,and retain separate virtual or logical addresses, or may reside onseparate physical machines. FIG. 1 illustrates just one example of anetwork architecture that may be used, and those of skill in the artwill appreciate that the specific network architecture and dataprocessing devices used may vary, and are secondary to the functionalitythat they provide, as further described herein. For example, servicesprovided by web server 105 and data server 103 may be combined on asingle server.

Each component 103, 105, 107, 109 may be any type of known computer,server, or data processing device. Data server 103, e.g., may include aprocessor 111 controlling overall operation of the rate server 103. Dataserver 103 may further include RAM 113, ROM 115, network interface 117,input/output interfaces 119 (e.g., keyboard, mouse, display, printer,etc.), and memory 121. I/O 119 may include a variety of interface unitsand drives for reading, writing, displaying, and/or printing data orfiles. Memory 121 may further store operating system software 123 forcontrolling overall operation of the data processing device 103, controllogic 125 for instructing data server 103 to perform aspects describedherein, and other application software 127 providing secondary, support,and/or other functionality which may or may not be used in conjunctionwith aspects described herein. The control logic may also be referred toherein as the data server software 125. Functionality of the data serversoftware may refer to operations or decisions made automatically basedon rules coded into the control logic, made manually by a user providinginput into the system, and/or a combination of automatic processingbased on user input (e.g., queries, data updates, etc.).

Memory 121 may also store data used in performance of one or moreaspects described herein, including a first database 129 and a seconddatabase 131. In some embodiments, the first database may include thesecond database (e.g., as a separate table, report, etc.). That is, theinformation can be stored in a single database, or separated intodifferent logical, virtual, or physical databases, depending on systemdesign. Devices 105, 107, 109 may have similar or different architectureas described with respect to device 103. Those of skill in the art willappreciate that the functionality of data processing device 103 (ordevice 105, 107, 109) as described herein may be spread across multipledata processing devices, for example, to distribute processing loadacross multiple computers, to segregate transactions based on geographiclocation, user access level, quality of service (QoS), etc.

One or more aspects may be embodied in computer-usable or readable dataand/or computer-executable instructions, such as in one or more programmodules, executed by one or more computers or other devices as describedherein. Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types when executed by a processor ina computer or other device. The modules may be written in a source codeprogramming language that is subsequently compiled for execution, or maybe written in a scripting language such as (but not limited to)Javascript or ActionScript. The computer executable instructions may bestored on a computer readable medium such as a nonvolatile storagedevice. Any suitable computer readable storage media may be utilized,including hard disks, CD-ROMs, optical storage devices, magnetic storagedevices, and/or any combination thereof. In addition, varioustransmission (non-storage) media representing data or events asdescribed herein may be transferred between a source and a destinationin the form of electromagnetic waves traveling through signal-conductingmedia such as metal wires, optical fibers, and/or wireless transmissionmedia (e.g., air and/or space). Various aspects described herein may beembodied as a method, a data processing system, or a computer programproduct. Therefore, various functionalities may be embodied in whole orin part in software, firmware and/or hardware or hardware equivalentssuch as integrated circuits, field programmable gate arrays (FPGA), andthe like. Particular data structures may be used to more effectivelyimplement one or more aspects described herein, and such data structuresare contemplated within the scope of computer executable instructionsand computer-usable data described herein.

With further reference to FIG. 2, some aspects described herein may beimplemented in a cloud-based environment. FIG. 2 illustrates an exampleof a cloud computing environment (or cloud system) 400. As seen in FIG.2, client computers 211-214 may communicate with a cloud managementserver 210 to access the computing resources (e.g., host servers 203,storage resources 204, and network resources 205) of the cloud system.

Management server 210 may be implemented on one or more physicalservers. The management server 210 may run, for example, CLOUDSTACK byCitrix Systems, Inc. of Ft. Lauderdale, Fla., or OPENSTACK, amongothers. Management server 210 may manage various computing resources,including cloud hardware and software resources, for example, hostcomputers 203, data storage devices 204, and networking devices 205. Thecloud hardware and software resources may include private and/or publiccomponents. For example, a cloud may be configured as a private cloud tobe used by one or more particular customers or client computers 211-214and/or over a private network. In other embodiments, public clouds orhybrid public-private clouds may be used by other customers over an openor hybrid networks.

Management server 210 may be configured to provide user interfacesthrough which cloud operators and cloud customers may interact with thecloud system. For example, the management server 210 may provide a setof APIs and/or one or more cloud operator console applications (e.g.,web-based or standalone applications) with user interfaces to allowcloud operators to manage the cloud resources, configure thevirtualization layer, manage customer accounts, and perform other cloudadministration tasks. The management server 210 also may include a setof APIs and/or one or more customer console applications with userinterfaces configured to receive cloud computing requests from end usersvia client computers 211-214, for example, requests to create, modify,or destroy virtual machines within the cloud. Client computers 211-214may connect to management server 210 via the Internet or othercommunication network, and may request access to one or more of thecomputing resources managed by management server 210. In response toclient requests, the management server 210 may include a resourcemanager configured to select and provision physical resources in thehardware layer of the cloud system based on the client requests. Forexample, the management server 210 and additional components of thecloud system may be configured to provision, create, and manage virtualmachines and their operating environments (e.g., hypervisors, storageresources, services offered by the network elements, etc.) for customersat client computers 211-214, over a network (e.g., the Internet),providing customers with computational resources, data storage services,networking capabilities, and computer platform and application support.Cloud systems also may be configured to provide various specificservices, including security systems, development environments, userinterfaces, and the like.

Certain clients 211-214 may be related, for example, different clientcomputers creating virtual machines on behalf of the same end user, ordifferent users affiliated with the same company or organization. Inother examples, certain clients 211-214 may be unrelated, such as usersaffiliated with different companies or organizations. For unrelatedclients, information on the virtual machines or storage of any one usermay be hidden from other users.

Referring now to the physical hardware layer of a cloud computingenvironment, availability zones 201-202 (or zones) may refer to acollocated set of physical computing resources. Zones may begeographically separated from other zones in the overall cloud ofcomputing resources. For example, zone 201 may be a first clouddatacenter located in California, and zone 202 may be a second clouddatacenter located in Florida. Management sever 210 may be located atone of the availability zones, or at a separate location. Each zone mayinclude an internal network that interfaces with devices that areoutside of the zone, such as the management server 210, through agateway. End users of the cloud (e.g., clients 211-214) might or mightnot be aware of the distinctions between zones. For example, an end usermay request the creation of a virtual machine having a specified amountof memory, processing power, and network capabilities. The managementserver 210 may respond to the user's request and may allocate theresources to create the virtual machine without the user knowing whetherthe virtual machine was created using resources from zone 201 or zone202. In other examples, the cloud system may allow end users to requestthat virtual machines (or other cloud resources) are allocated in aspecific zone or on specific resources 203-205 within a zone.

In this example, each zone 201-202 may include an arrangement of variousphysical hardware components (or computing resources) 203-205, forexample, physical hosting resources (or processing resources), physicalnetwork resources, physical storage resources, switches, and additionalhardware resources that may be used to provide cloud computing servicesto customers. The physical hosting resources in a cloud zone 201-202 mayinclude one or more computer servers 203, such as virtualizationservers, which may be configured to create and host virtual machineinstances. The physical network resources in a cloud zone 201 or 202 mayinclude one or more network elements 205 (e.g., network serviceproviders) comprising hardware and/or software configured to provide anetwork service to cloud customers, such as firewalls, network addresstranslators, load balancers, virtual private network (VPN) gateways,Dynamic Host Configuration Protocol (DHCP) routers, and the like. Thestorage resources in the cloud zone 201-202 may include storage disks(e.g., solid state drives (SSDs), magnetic hard disks, etc.) and otherstorage devices.

The example cloud computing environment shown in FIG. 2 also may includea virtualization layer with additional hardware and/or softwareresources configured to create and manage virtual machines and provideother services to customers using the physical resources in the cloud.The virtualization layer may include one or more hypervisors, along withother components to provide network virtualizations, storagevirtualizations, etc. The virtualization layer may be as a separatelayer from the physical resource layer, or may share some or all of thesame hardware and/or software resources with the physical resourcelayer. For example, the virtualization layer may include a hypervisorinstalled in each of the virtualization servers 203 with the physicalcomputing resources. Known cloud systems may alternatively be used,e.g., WINDOWS AZURE (Microsoft Corporation of Redmond Wash.), AMAZON EC2(Amazon.com Inc. of Seattle, Wash.), IBM BLUE CLOUD (IBM Corporation ofArmonk, N.Y.), or others.

3. ENTERPRISE MOBILITY MANAGEMENT ARCHITECTURE

FIG. 3 represents an enterprise mobility technical architecture 300 foruse in an enterprise environment, a BYOD environment, or other mobileenvironments. The architecture enables a user of a mobile device 302(e.g., as client 107, 211, or otherwise) to both access enterprise orpersonal resources from a mobile device 302 and use the mobile device302 for personal use. The user may access such enterprise resources 304or enterprise services 308 using a mobile device 302 that is purchasedby the user or a mobile device 302 that is provided by the enterprise tothe user. The user may utilize the mobile device 302 for business useonly or for business and personal use. The mobile device may run an iOSoperating system, Android operating system, and/or the like. Theenterprise may choose to implement policies to manage the mobile device304. The policies may be implanted through a firewall or gateway in sucha way that the mobile device may be identified, secured or securityverified, and provided selective or full access to the enterpriseresources. The policies may be mobile device management policies, mobileapplication management policies, mobile data management policies, orsome combination of mobile device, application, and data managementpolicies. A mobile device 304 that is managed through the application ofmobile device management policies may be referred to as an enrolleddevice or managed device.

In some embodiments, the operating system of the mobile device may beseparated into a managed partition 310 and an unmanaged partition 312.The managed partition 310 may have policies applied to it to secure theapplications running on and data stored in the managed partition. Inother embodiments, all applications may execute in accordance with a setof one or more policy files received separate from the application, andwhich define one or more security parameters, features, resourcerestrictions, and/or other access controls that are enforced by themobile device management system when that application is executing onthe device. By operating in accordance with their respective policyfile(s), each application may be allowed or restricted fromcommunications with one or more other applications and/or resources,thereby creating a virtual partition. Thus, as used herein, a partitionmay refer to a physically partitioned portion of memory (physicalpartition), a logically partitioned portion of memory (logicalpartition), and/or a virtual partition created as a result ofenforcement of one or more policies and/or policy files across multipleapps as described herein (virtual partition). Stated differently, byenforcing policies on managed apps, those apps may be restricted to onlybe able to communicate with other managed apps and trusted enterpriseresources, thereby creating a virtual partition that is impenetrable byunmanaged apps and devices.

The applications running on the managed partition may be secureapplications. The secure applications may be email applications, webbrowsing applications, software-as-a-service (SaaS) access applications,Windows Application access applications, and the like. The secureapplications may be secure native applications 314, secure remoteapplications 322 executed by a secure application launcher 318,virtualization applications 326 executed by a secure applicationlauncher 318, and the like. The secure native applications 314 may bewrapped by a secure application wrapper 320. The secure applicationwrapper 320 may include integrated policies that are executed on themobile device 302 when the secure native application is executed on thedevice. The secure application wrapper 320 may include meta-data thatpoints the secure native application 314 running on the mobile device302 to the resources hosted at the enterprise that the secure nativeapplication 314 may require to complete the task requested uponexecution of the secure native application 314. The secure remoteapplications 322 executed by a secure application launcher 318 may beexecuted within the secure application launcher application 318. Thevirtualization applications 326 executed by a secure applicationlauncher 318 may utilize resources on the mobile device 302, at theenterprise resources 304, and the like. The resources used on the mobiledevice 302 by the virtualization applications 326 executed by a secureapplication launcher 318 may include user interaction resources,processing resources, and the like. The user interaction resources maybe used to collect and transmit keyboard input, mouse input, camerainput, tactile input, audio input, visual input, gesture input, and thelike. The processing resources may be used to present a user interface,process data received from the enterprise resources 304, and the like.The resources used at the enterprise resources 304 by the virtualizationapplications 326 executed by a secure application launcher 318 mayinclude user interface generation resources, processing resources, andthe like. The user interface generation resources may be used toassemble a user interface, modify a user interface, refresh a userinterface, and the like. The processing resources may be used to createinformation, read information, update information, delete information,and the like. For example, the virtualization application may recorduser interactions associated with a GUI and communicate them to a serverapplication where the server application will use the user interactiondata as an input to the application operating on the server. In thisarrangement, an enterprise may elect to maintain the application on theserver side as well as data, files, etc. associated with theapplication. While an enterprise may elect to “mobilize” someapplications in accordance with the principles herein by securing themfor deployment on the mobile device, this arrangement may also beelected for certain applications. For example, while some applicationsmay be secured for use on the mobile device, others may not be preparedor appropriate for deployment on the mobile device so the enterprise mayelect to provide the mobile user access to the unprepared applicationsthrough virtualization techniques. As another example, the enterprisemay have large complex applications with large and complex data sets(e.g. material resource planning applications) where it would be verydifficult, or otherwise undesirable, to customize the application forthe mobile device so the enterprise may elect to provide access to theapplication through virtualization techniques. As yet another example,the enterprise may have an application that maintains highly secureddata (e.g. human resources data, customer data, engineering data) thatmay be deemed by the enterprise as too sensitive for even the securedmobile environment so the enterprise may elect to use virtualizationtechniques to permit mobile access to such applications and data. Anenterprise may elect to provide both fully secured and fully functionalapplications on the mobile device as well as a virtualizationapplication to allow access to applications that are deemed moreproperly operated on the server side. In an embodiment, thevirtualization application may store some data, files, etc. on themobile phone in one of the secure storage locations. An enterprise, forexample, may elect to allow certain information to be stored on thephone while not permitting other information.

In connection with the virtualization application, as described herein,the mobile device may have a virtualization application that is designedto present GUI's and then record/pass-through user interactions with theGUI. The application may communicate the user interactions to the serverside to be used by the server side application as user interactions withthe application. In response, the application on the server side maytransmit back to the mobile device a new GUI. For example, the new GUImay be a static page, a dynamic page, an animation, or the like, therebyproviding access to remotely located resources.

The secure applications may access data stored in a secure datacontainer 328 in the managed partition 310 of the mobile device. Thedata secured in the secure data container may be accessed by the securewrapped applications 314, applications executed by a secure applicationlauncher 318, virtualization applications 326 executed by a secureapplication launcher 318, and the like. The data stored in the securedata container 328 may include files, databases, and the like. The datastored in the secure data container 328 may include data restricted to aspecific secure application 330, shared among secure applications 332,and the like. Data restricted to a secure application may include securegeneral data 334 and highly secure data 338. Secure general data may usea strong form of encryption such as AES 128-bit encryption or the like,while highly secure data 338 may use a very strong form of encryptionsuch as AES 256-bit encryption. Data stored in the secure data container328 may be deleted from the device upon receipt of a command from thedevice manager 324. The secure applications may have a dual-mode option340. The dual mode option 340 may present the user with an option tooperate the secured application in an unsecured mode. In an unsecuredmode, the secure applications may access data stored in an unsecureddata container 342 on the unmanaged partition 312 of the mobile device302. The data stored in an unsecured data container may be personal data344. The data stored in an unsecured data container 342 may also beaccessed by unsecured applications 348 that are running on the unmanagedpartition 312 of the mobile device 302. The data stored in an unsecureddata container 342 may remain on the mobile device 302 when the datastored in the secure data container 328 is deleted from the mobiledevice 302. An enterprise may want to delete from the mobile deviceselected or all data, files, and/or applications owned, licensed orcontrolled by the enterprise (enterprise data) while leaving orotherwise preserving personal data, files, and/or applications owned,licensed or controlled by the user (personal data). This operation maybe referred to as a selective wipe. With the enterprise and personaldata arranged in accordance to the aspects described herein, anenterprise may perform a selective wipe.

The mobile device may connect to enterprise resources 304 and enterpriseservices 308 at an enterprise, to the public Internet 348, and the like.The mobile device may connect to enterprise resources 304 and enterpriseservices 308 through virtual private network connections. The virtualprivate network connections (also referred to as microVPN orapplication-specific VPN) may be specific to particular applications350, particular devices, particular secured areas on the mobile device,and the like (e.g., 352). For example, each of the wrapped applicationsin the secured area of the phone may access enterprise resources throughan application specific VPN such that access to the VPN would be grantedbased on attributes associated with the application, possibly inconjunction with user or device attribute information. The virtualprivate network connections may carry Microsoft Exchange traffic,Microsoft Active Directory traffic, HTTP traffic, HTTPS traffic,application management traffic, and the like. The virtual privatenetwork connections may support and enable single-sign-on authenticationprocesses 354. The single-sign-on processes may allow a user to providea single set of authentication credentials, which are then verified byan authentication service 358. The authentication service 358 may thengrant to the user access to multiple enterprise resources 304, withoutrequiring the user to provide authentication credentials to eachindividual enterprise resource 304.

The virtual private network connections may be established and managedby an access gateway 360. The access gateway 360 may include performanceenhancement features that manage, accelerate, and improve the deliveryof enterprise resources 304 to the mobile device 302. The access gatewaymay also re-route traffic from the mobile device 302 to the publicInternet 348, enabling the mobile device 302 to access publiclyavailable and unsecured applications that run on the public Internet348. The mobile device may connect to the access gateway via a transportnetwork 362. The transport network 362 may be a wired network, wirelessnetwork, cloud network, local area network, metropolitan area network,wide area network, public network, private network, and the like.

The enterprise resources 304 may include email servers, file sharingservers, SaaS applications, Web application servers, Windows applicationservers, and the like. Email servers may include Exchange servers, LotusNotes servers, and the like. File sharing servers may include SHAREFILEservers, other file sharing services, and the like. SaaS applicationsmay include Salesforce, and the like. Windows application servers mayinclude any application server that is built to provide applicationsthat are intended to run on a local Windows operating system, and thelike. The enterprise resources 304 may be premise-based resources, cloudbased resources, and the like. The enterprise resources 304 may beaccessed by the mobile device 302 directly or through the access gateway360. The enterprise resources 304 may be accessed by the mobile device302 via a transport network 362. The transport network 362 may be awired network, wireless network, cloud network, local area network,metropolitan area network, wide area network, public network, privatenetwork, and the like.

The enterprise services 308 may include authentication services 358,threat detection services 364, device manager services 324, file sharingservices 368, policy manager services 370, social integration services372, application controller services 374, and the like. Authenticationservices 358 may include user authentication services, deviceauthentication services, application authentication services, dataauthentication services and the like. Authentication services 358 mayuse certificates. The certificates may be stored on the mobile device302, by the enterprise resources 304, and the like. The certificatesstored on the mobile device 302 may be stored in an encrypted locationon the mobile device, the certificate may be temporarily stored on themobile device 302 for use at the time of authentication, and the like.Threat detection services 364 may include intrusion detection services,unauthorized access attempt detection services, and the like.Unauthorized access attempt detection services may include unauthorizedattempts to access devices, applications, data, and the like. Devicemanagement services 324 may include configuration, provisioning,security, support, monitoring, reporting, and decommissioning services.File sharing services 368 may include file management services, filestorage services, file collaboration services, and the like. Policymanager services 370 may include device policy manager services,application policy manager services, data policy manager services, andthe like. Social integration services 372 may include contactintegration services, collaboration services, integration with socialnetworks such as Facebook, Twitter, and LinkedIn, and the like.Application controller services 374 may include management services,provisioning services, deployment services, assignment services,revocation services, wrapping services, and the like.

The enterprise mobility technical architecture 300 may include anapplication store/distribution portal 378. The application store 378 mayinclude unwrapped applications 380, pre-wrapped applications 382, andthe like. Applications may be populated in the application store 378from the application controller 374, e.g., by an administratorresponsible for app prep, app publishing, app updates, role assignment,and/or policy definition and selection, among other functions. Theapplication store 378 may be accessed by the mobile device 302 throughthe access gateway 360, through the public Internet 348 (optionallythrough a secure firewall), or the like. The application store may beprovided with an intuitive and easy to use user interface. Theapplication store 378 may provide access to a software developmentkit/self-installation kit 384. The software development kit 384 mayprovide a user the capability to secure unmanaged applications selectedby the user by wrapping the application as described herein. Anapplication that has been wrapped using the software development kit 384may then be made available to the mobile device 302, e.g., by installingthe wrapped version of the app, by sending the application store 378 forapproval, and/or by directly populating it in the application store 378using the application controller 374.

The enterprise mobility technical architecture 300 may include amanagement and analytics capability. The management and analyticscapability may provide information related to how resources are used,how often resources are used, and the like. Resources may includedevices, applications, data, and the like. How resources are used mayinclude which devices download which applications, which applicationsaccess which data, and the like. How often resources are used mayinclude how often an application has been downloaded, how many times aspecific set of data has been accessed by an application, and the like.

FIG. 4 is another illustrative enterprise mobility management system400. Some of the components of the mobility management system 300described above with reference to FIG. 3 have been omitted for the sakeof simplicity. The architecture of the system 400 depicted in FIG. 4 issimilar in many respects to the architecture of the system 300 describedabove with reference to FIG. 3 and may include additional features notmentioned above.

In this case, the left hand side represents an enrolled/managed mobiledevice 402 (e.g., client 107, 212, 302, etc.) with a client agent 404,which interacts with gateway server 406 (which includes access gatewayand application controller functionality) to access various enterpriseresources 408 and services 409 such as Exchange, Sharepoint, PKIResources, Kerberos Resources, and Certificate Issuance Service, asshown on the right hand side above. Although not specifically shown, themobile device 402 may also interact with an enterprise application store(e.g., an app store, storefront, or the like) for the selection anddownloading of applications.

The client agent 404 acts as the UI (user interface) intermediary forWindows apps/desktops hosted in an Enterprise data center, which areaccessed using the HDX/ICA display remoting protocol, or any otherremoting protocol. The client agent 404 also supports the installationand management of native applications on the mobile device 402, such asnative iOS or Android applications. For example, the managedapplications 410 (mail, browser, wrapped application) shown in thefigure above are all native applications that execute locally on thedevice. Client agent 404 and an application management framework, suchas MDX (mobile experience technology) by Citrix Systems Inc. of FortLauderdale, Florida (other application management frameworks may also beused), act to provide policy driven management capabilities and featuressuch as connectivity and SSO (single sign on) to enterpriseresources/services 408. The client agent 404 handles primary userauthentication to the enterprise, normally to the access gateway (AG)with SSO to other gateway server components. The client agent 404obtains policies from gateway server 406 to control the behavior of themanaged applications 410 on the mobile device 402. As used herein, amanaged application is one that is capable of being controlled based onand operated in accordance with independently defined and communicatedpolicy files.

The secure IPC links 412 between the native applications 410 and clientagent 404 represent a management channel, which allows client agent tosupply policies to be enforced by the application management framework414 “wrapping” each application. The IPC channel 412 also allows clientagent 404 to supply credential and authentication information thatenables connectivity and SSO to enterprise resources 408. Finally theIPC channel 412 allows the application management framework 414 toinvoke user interface functions implemented by client agent 404, such asonline and offline authentication.

Communications between the client agent 404 and gateway server 406 areessentially an extension of the management channel from the applicationmanagement framework 414 wrapping each native managed application 410.The application management framework 414 requests policy informationfrom client agent 404, which in turn requests it from gateway server406. The application management framework 414 requests authentication,and client agent 404 logs into the gateway services part of gatewayserver 406 (also known as NetScaler Access Gateway). Client agent 404may also call supporting services on gateway server 406, which mayproduce input material to derive encryption keys for the local datavaults 416, or provide client certificates which may enable directauthentication to PKI protected resources, as more fully explainedbelow.

In more detail, the application management framework 414 “wraps” eachmanaged application 410. This may be incorporated via an explicit buildstep, or via a post-build processing step. The application managementframework 414 may “pair” with client agent 614 on first launch of anapplication 410 to initialize the secure IPC channel and obtain thepolicy for that application. The application management framework 414may enforce relevant portions of the policy that apply locally, such asthe client agent login dependencies and some of the containment policiesthat restrict how local OS services may be used, or how they mayinteract with the application 410.

The application management framework 414 may use services provided byclient agent 404 over the secure IPC channel 412 to facilitateauthentication and internal network access. Key management for theprivate and shared data vaults 416 (containers) may be also managed byappropriate interactions between the managed applications 410 and clientagent 404. Vaults 416 may be available only after online authentication,or may be made available after offline authentication if allowed bypolicy. First use of vaults 416 may require online authentication, andoffline access may be limited to at most the policy refresh periodbefore online authentication is again required.

Network access to internal resources may occur directly from individualmanaged applications 410 through access gateway 406. The applicationmanagement framework 414 is responsible for orchestrating the networkaccess on behalf of each application 410. Client agent 404 mayfacilitate these network connections by providing suitable time limitedsecondary credentials obtained following online authentication. Multiplemodes of network connection may be used, such as reverse web proxyconnections and end-to-end VPN-style tunnels 418.

The mail and browser managed applications 410 have special status andmay make use of facilities that might not be generally available toarbitrary wrapped applications. For example, the mail application mayuse a special background network access mechanism that allows it toaccess Exchange over an extended period of time without requiring a fullAD logon. The browser application may use multiple private data vaultsto segregate different kinds of data.

This architecture supports the incorporation of various other securityfeatures. For example, gateway server 406 (including its gatewayservices) in some cases will not need to validate AD passwords. It canbe left to the discretion of an enterprise whether an AD password isused as an authentication factor for some users in some situations.Different authentication methods may be used if a user is online oroffline (i.e., connected or not connected to a network).

Step up authentication is a feature wherein gateway server 406 mayidentify managed native applications 410 that are allowed to have accessto highly classified data requiring strong authentication, and ensurethat access to these applications is only permitted after performingappropriate authentication, even if this means a re-authentication isrequired by the user after a prior weaker level of login.

Another security feature of this solution is the encryption of the datavaults 416 (containers) on the mobile device 402. The vaults 416 may beencrypted so that all on-device data including files, databases, andconfigurations are protected. For on-line vaults, the keys may be storedon the server (gateway server 406), and for off-line vaults, a localcopy of the keys may be protected by a user password (or other securitykey, e.g., biometric, etc.). When data is stored locally on the device402 in the secure container 416, it is preferred that a minimum of AES256 encryption algorithm be utilized.

Other secure container features may also be implemented. For example, alogging feature may be included, wherein all security events happeninginside an application 410 are logged and reported to the backend. Datawiping may be supported, such as if the application 410 detectstampering, associated encryption keys may be written over with randomdata, leaving no hint on the file system that user data was destroyed.Screenshot protection is another feature, where an application mayprevent any data from being stored in screenshots. For example, the keywindow's hidden property may be set to YES. This may cause whatevercontent is currently displayed on the screen to be hidden, resulting ina blank screenshot where any content would normally reside.

Local data transfer may be prevented, such as by preventing any datafrom being locally transferred outside the application container, e.g.,by copying it or sending it to an external application. A keyboard cachefeature may operate to disable the autocorrect functionality forsensitive text fields. SSL certificate validation may be operable so theapplication specifically validates the server SSL certificate instead ofit being stored in the keychain. An encryption key generation featuremay be used such that the key used to encrypt data on the device isgenerated using a passphrase or biometric data supplied by the user (ifoffline access is required). It may be XORed with another key randomlygenerated and stored on the server side if offline access is notrequired. Key derivation functions may operate such that keys generatedfrom the user password use KDFs (key derivation functions, notablyPBKDF2) rather than creating a cryptographic hash of it. The lattermakes a key susceptible to brute force or dictionary attacks.

Further, one or more initialization vectors may be used in encryptionmethods. An initialization vector will cause multiple copies of the sameencrypted data to yield different cipher text output, preventing bothreplay and cryptanalytic attacks. This will also prevent an attackerfrom decrypting any data even with a stolen encryption key if thespecific initialization vector used to encrypt the data is not known.Further, authentication then decryption may be used, wherein applicationdata is decrypted only after the user has authenticated within theapplication. Another feature may relate to sensitive data in memory,which may be kept in memory (and not in disk) only when it's needed. Forexample, login credentials may be wiped from memory after login, andencryption keys and other data inside objective-C instance variables arenot stored, as they may be easily referenced. Instead, memory may bemanually allocated for these.

An inactivity timeout may be implemented, wherein after a policy-definedperiod of inactivity, a user session is terminated.

Data leakage from application management framework 414 may be preventedin other ways. For example, when an application 410 is put in thebackground, the memory may be cleared after a predetermined(configurable) time period. When backgrounded, a snapshot may be takenof the last displayed screen of the application to expedite theforegrounding process. The screenshot may contain confidential data andhence should be cleared.

Another security feature relates to the use of an OTP (one timepassword) 420 without the use of an AD (active directory) 422 passwordfor access to one or more applications. In some cases, some users do notknow (or are not permitted to know) their AD password, so these usersmay authenticate using an OTP 420 such as by using a hardware OTP systemlike SecurID (OTPs may be provided by different vendors also, such asEntrust or Gemalto). In some cases, after a user authenticates with auser ID, a text is sent to the user with an OTP 420. In some cases, thismay be implemented only for online use, with a prompt being a singlefield.

An offline password (or biometric authentication) may be implemented foroffline authentication for those applications 410 for which offline useis permitted via enterprise policy. For example, an enterprise may wantthe enterprise application store to be accessed in this manner. In thiscase, the client agent 404 may require the user to set a custom offlinepassword and the AD password is not used. Gateway server 406 may providepolicies to control and enforce password standards with respect to theminimum length, character class composition, and age of passwords, suchas described by the standard Windows Server password complexityrequirements, although these requirements may be modified. Biometricauthentication may also or alternatively be used for one or both ofoffline authentication as well as a source of entropy for key derivationfunctions.

Another feature relates to the enablement of a client side certificatefor certain applications 410 as secondary credentials (for the purposeof accessing PKI protected web resources via the application managementframework micro VPN feature). For example, an application such as acorporate email application may utilize such a certificate. In thiscase, certificate-based authentication using ActiveSync protocol may besupported, wherein a certificate from the client agent 404 may beretrieved by gateway server 406 and used in a keychain. Each managedapplication may have one associated client certificate, identified by alabel that is defined in gateway server 406.

Gateway server 406 may interact with an enterprise special purpose webservice to support the issuance of client certificates to allow relevantmanaged applications to authenticate to internal PKI protectedresources. Alternatively, client certificates may be issued by accessgateway 360. In another example, client certificates may be provided byan EMM/MRM server (e.g., at the device level), and/or by an appcontroller that provisions certificates based on application-levelpolicies.

The client agent 404 and application management framework 414 may beenhanced to support obtaining and using client certificates forauthentication to internal PKI protected network resources. More thanone certificate may be supported, such as to match various levels ofsecurity and/or separation requirements. The certificates may be used bythe mail and browser managed applications, and ultimately by arbitrarywrapped applications (provided those applications use web service stylecommunication patterns where it is reasonable for application managementframework to mediate HTTPS requests).

Application management framework client certificate support on iOS mayrely on importing a PKCS 12 BLOB (Binary Large Object) into the iOSkeychain (or other container managed secrets vault protected bypassword, biometric validation, or other credentials) in each managedapplication for each period of use. Application management frameworkclient certificate support may use a HTTPS implementation with privatein-memory key storage. The client certificate will never be present inthe iOS keychain and will not be persisted except potentially in“online-only” data value that is strongly protected.

Mutual SSL may also be implemented to provide additional security byrequiring that a mobile device 402 is authenticated to the enterprise,and vice versa. Virtual smart cards for authentication to gateway server406 may also be implemented.

Both limited and full Kerberos support may be additional features. Thefull support feature relates to an ability to do full Kerberos login toAD 422, using an AD password or trusted client certificate, and obtainKerberos service tickets to respond to HTTP negotiate authenticationchallenges. The limited support feature relates to constraineddelegation in the access gateway software, where the software supportsinvoking Kerberos protocol transition so it can obtain and use Kerberosservice tickets (subject to constrained delegation) in response to HTTPnegotiate authentication challenges. This mechanism works in reverse webproxy mode, and when HTTP (but not HTTPS) connections are proxied in VPNand MicroVPN mode.

Another feature relates to application container locking and wiping,which may automatically occur upon jail-break or rooting detections, andoccur as a pushed command from administration console, and may include aremote wipe functionality even when an application 410 is not running.

A multi-site architecture or configuration of the enterprise applicationstore and application controller may be supported that allows users tobe service from one of several different locations in case of failure.

In some cases, managed applications 410 may be allowed to access acertificate and private key via an API (example OpenSSL). Trustedmanaged applications 410 of an enterprise may be allowed to performspecific Public Key operations with an application's client certificateand private key. Various use cases may be identified and treatedaccordingly, such as when an application behaves like a browser and nocertificate access is required, when an application reads a certificatefor “who am I,” when an application uses the certificate to build asecure session token, and when an application uses private keys fordigital signing of important data (e.g. transaction log) or fortemporary data encryption.

Other features may also be controlled, managed, enabled, disabled,locked, unlocked, blocked, unblocked, or otherwise modified based onpolicy, user information, or other security information. Anon-exhaustive list of features includes printing, data backup, locationservices, camera access, microphone access, data port access, access toremovable storage, URL and other inter-app dispatching, access to othermobile device hardware such as biometric devices, accelerometers,proximity sensors, NFC, etc., and access to other system services suchas sending SMS messages, sending email messages, network access, and thelike.

4. POLICY-BASED APPLICATION MANAGEMENT

Improved techniques involve imposing control over managed applicationsusing one or more policy files. A managed application may be a nativelymanaged application, or may be derived from an unmanaged application.Once a managed application has been installed on electronic equipmentsuch as an electronic mobile device, the managed application mayoperates based on one or more policies which may be updated locally onthe mobile device in a routine manner, by an administrator, enterprise,etc.

For example, an application source such as an app store, a softwaredeveloper, etc. may operate as a repository of unmanaged apps(applications which are not under local policy control). An unmanagedapp from the application source may then be decompiled, augmented with aset of instructions that impose control based on a set of one or moreadministrative policies, and then recompiled to form a managedapplication. The managed application is then offered through anapplication source (e.g., the same app store, a different app store, anenterprise application server, etc.) for use by mobile devices.

Once the managed application is installed on a mobile device, themanaged application accesses, and operates in accordance with, a set ofone or more policies (further described herein) which are separatelymaintained on the mobile device. Additionally, the managed applicationmay request an updated set of policies from the application source andoperate in accordance with the updated set of policies over time and ina routine manner.

FIG. 5 shows an illustrative environment 500 which may be used to deployand manage/administer managed apps. The electronic environment mayinclude an application source 502, a software converting equipment 504running a specialized software utility, a app store server 506, and amobile device 508 (e.g., a smart phone, a tablet, client 107, 211,etc.).

It should be understood that application source 502 and app store server506 are shown as separate apparatus although, in some arrangements, theymay be the same apparatus. In some arrangements, users of mobile devicespurchase managed applications from app store server 506, and the appstore server operates as both a vehicle for distributing the managedapplications as well as a policy server for distributing policies whichcontrol how the managed applications operate on the mobile devices.

It should be understood that the various apparatus of the electronicenvironment are computerized and communicate via electronic signals. Forexample, each computerized apparatus may include a communicationsinterface to connect to a communications medium such as a network,memory to cache and/or persistently store information, and processingcircuitry to execute an operating system and local applications.

During operation, conversion equipment 504 may run a specializedsoftware utility which receives an unmanaged app from a software source(see step 1). The conversion equipment, when running in accordance withthe specialized software utility, decompiles the unmanaged app, e.g.,into DEX file(s) (Android), human readable source code, or some othereditable format. The conversion equipment may then modify the humanreadable source code or DEX file(s) to include policy control features.In particular, the conversion equipment is constructed and arranged toanalyze (e.g., scan and identify) activities and appropriate locationsto inject policy based control instructions into the human readablesource code or DEX file(s). The policy based control instructions act tolimit how the app operates based on one or more received policy files.The conversion equipment then recompiles the human readable source codeor DEX file(s) to form a managed app. Alternatively, where code is notcapable of decompilation (e.g., iOS), symbol table manipulation of theapplication binary may be used to inject managed code by adding newlibrary references. Run-time hooks may also be added to interceptmanaged functions within the application.

App store server 506 may then load the managed apps from the conversionequipment (see step 2) thus making the managed app available fordistribution. Additionally, an administrator may provide policies whichcontrol the operation of the managed apps, and such policies may also bemade available on the app store server for distribution.

Users of mobile devices 508 are able to browse apps offered by the appstore server via app store apps installed on the mobile devices. When auser of a mobile device wishes to acquire a managed app (e.g., via apurchase), the user directs the app store app on the mobile device torequest the managed app (see step 3). The app store server response tothe app request by providing the managed app to the mobile device (seestep 4).

The user then installs the managed app on mobile device 508 (see step5). Such installation may be automatically triggered by the app storeapp (e.g., the app store app automatically directs the operating systemto install the managed app), or manually coordinated by the user.

When the user initially invokes the managed app 510, the managed app maycommunicate with the app store app 512 to obtain a set of policies (seestep 6). Such a set of policies may have been provided to the app storeapp from the app store server during purchase. However, if the set ofpolicies is not present, the app store app sends a policy request to theapp store server for a set of policies (see step 7). In response to thepolicy request, the app store server provides the set of policies to themobile device (see step 8). It should be understood that the set ofpolicies and the managed app are separate software constructs.

At this point, the managed app is able to run in accordance with the setof policies and thus enable the user to perform useful work (see step9). Optionally, the set of policies may dictate times in which themanaged app is to request an updated set of policies. For example, theset of policies may direct the managed app to obtain a new set ofpolicies daily, every two or three days, and so on.

When the managed app requires a new set of policies, the managed appsignals or queries the app store app to retrieve the new set of policiesfrom the app store server (see step 6 again). That is, the app store appoperates as a proxy and obtains the new set of policies from the appstore server on behalf of the managed app. In some arrangements, themobile device runs multiple managed apps, and the same app store appcommunicates with the app store server on behalf of each managed app.

One embodiment is directed to a method of generating a managedapplication from an unmanaged application. The method includesreceiving, by processing circuitry, an unmanaged application from anapplication source, the unmanaged application being constructed andarranged to execute on a mobile device. The method further includesdecompiling or otherwise deconstructing, by the processing circuitry,the unmanaged application into unmanaged editable form. The methodfurther includes adding, by the processing circuitry, a set of policybased control instructions to the unmanaged editable code to formmanaged source code, the set of policy based control instructions beingconstructed and arranged to provide policy based control. The methodfurther includes compiling, by the processing circuitry, the managedsource code to form a managed application which, when executed on amobile device, is constructed and arranged to access and operate inaccordance with a set of policies which is separately stored on themobile device.

Examples of suitable processing circuitry includes particular hardwareof various software development platforms such as servers, generalpurpose computers, client workstations, any hardware and/or softwaredescribed herein, and so on. Such platforms may be equipped with varioussoftware development tools including compilers, linkers, libraries,editors, debuggers, other runtime environment and test utilities, and soon.

Another embodiment is directed to a method of operating an electronicmobile device. The method includes receiving, by a processor of theelectronic mobile device, a managed application from an applicationserver during a first communication, the managed application beingconstructed and arranged to access and operate in accordance with a setof policies. The method further includes receiving, by the processor,the set of policies from the application server during a secondcommunication which is different than the first communication, the setof policies being stored on the electronic mobile device separately fromthe managed application. The method further includes running, by theprocessor, the managed application on the mobile device, the managedapplication accessing and operating in accordance with the set ofpolicies which is stored on the electronic mobile device separately fromthe managed application.

Other embodiments are directed to electronic systems and apparatus,processing circuits, computer program products, and so on. Someembodiments are directed to various processes, electronic components andcircuitry which are involved in generating, deploying and operatingmanaged apps derived from unmanaged apps.

Mobile devices allow users to purchase and download applications fortheir device from an external Web Site or Service commonly referred toas an app store or the like. The application that browses these appstore services is known as a app store-Application (a web browser mayalternatively be used). Once the app store Application has downloadedand installed an application, typically management of that applicationmay cease. For example, loss of entitlement to the application, orchanges to the allowed uses of the application, may not be maintained orenforced. Once the application is installed on a device, the enterpriseor corporation that distributed it may lose the ability to controlaccess to the application.

Many vendors offer conventional solutions that manage the entire device.For example, a user wishing to install managed applications must firstenroll their device into a corporate Enterprise Mobile Management system(EMM), which manages resources such as applications, (mobile applicationmanagement, or MAM), devices (mobile device management, or MDM),enterprise services to which a device may communicate (mobile enterprisemanagement), software, settings, features, remote tools, virtualizedapps, etc., and/or other features of a device and/or application. TheseEMM services typically require strict adherence to corporate securitypolicies, forcing the user to comply if they want to install theapplications, use a device in a particular manner, or connect with anenterprise service. In addition, by enrolling their device in an EMMsystem, often times the user must relinquish his/her control overcertain aspects of the device, such as the ability to not have apasscode or password set. Secure management and technical support ofmobile devices associated with an enterprise is referred to herein asEnterprise Mobility Management or Enterprise Mobile Management (EMM).Management of any device, application, or accessible tool is alsoreferred to herein as Mobile Resource Management (MRM). EMM and MRM mayinclude one or both of MDM and/or MAM, as discussed further herein.

Many employees would prefer to use their own devices but withoutenrolling their device in some EMM service. Accordingly, aspects hereinprovide a way for corporations to manage applications on unmanageddevices, e.g., in a Bring Your Own Device (BYOD) environment.

Improved techniques discussed above and herein provide various ways bywhich a corporation can add management to applications and devices, anddistribute those applications to unmanaged devices.

Some techniques are directed to a system and method for addingmanagement to applications that are to be distributed to unmanageddevices. The system includes an application running on a mobile devicethat acts as a app store application for downloading and installingother applications from one or more sites or services acting as a appstore. The system further includes a software utility that takes asinput an unmanaged application and outputs the same application withadditional management software added. The system further includes a setof security policies or rules that control how the managed applicationis expected to operate.

Some techniques are directed to methods which involve an administratorgenerating a managed application by submitting an unmanaged applicationto the software utility. The method includes the software utilitydecompiling the original application into byte code. The method furtherincludes modification of the byte code to inject the management softwareand components. The method further includes recompiling the modifiedapplication into a new and managed version of the application. Themethod further includes the managed application being posted to a appstore and made available for download and install by the app storeapplication. The method further includes the managed applicationperiodically contacting the app store application to confirm entitlementand to refresh the security policies.

Some improved techniques provide ways for an enterprise to providemanaged applications to unmanaged devices, alleviating the need toenroll the device into EMM systems. Some improved techniques provideways by which an enterprise can distribute and control access tospecific applications and data on devices that are not in its directcontrol, even if those applications were originally written with nomanagement software included.

Some techniques are directed to a software utility (and associatedmethods) which dynamically injects management code into existingunmanaged applications. In this way, even applications that wereoriginally developer without any management software can be added to thelist of enterprise managed applications.

Furthermore, the app store application now acts as an authentication andsecurity policy management application. This extends the intent and usefor a conventional app store application in an improved way, allowingfor management of specific applications on unmanaged devices.

Alternative conventional approaches usually involve either devicemanagement (where the entire device is enrolled into a managementsystem) or rewriting applications with specific management componentsadded as part of the core design of the application. However, with theabove-described improved techniques, control may be imposed anddynamically updated via policies which are routinely deployed locally tothe mobile devices to direct the operation of the managed apps.

It should be understood that the above-provided description may discussparticular operations of the applications figuratively (i.e., as theapplications performing the operations). However, it should be furtherunderstood that is actually processing circuitry (e.g., a set ofprocessors, other hardware, etc.) that actually performs operationswhile executing the applications.

Managed apps, i.e., apps that operate according to an enterprise-definedpolicy, may be configured to operate in countless ways. The managedconfiguration of the app is limited only by what is included in the oneor more policy files that apply to that app. In addition, managed appsmay run in a mobile device sandbox, or managed apps may run generally ona computing device and not within a formal sandbox generated by theoperating system of that device. The following sections provides variousillustrative examples of policies that may be used in combination withother technologies and aspects, but are in no way meant to be limitingof the types or numbers of policies that may be used.

5. DATA SHARING

According to an illustrative aspect, one or more policies used withmanaged applications, as described in section 4, above, may define howthe managed application operates to share data between applicationsexecuting on a mobile device.

FIG. 14 illustrates an example of such a process. Initially, a managedapplication may be received and/or installed in step 1401 on a mobileelectronic device, such as a smartphone, tablet, laptop or the like. Instep 1403 the device may separately and/or distinctly receive one ormore policy files defining one or more operational and/or behaviorallimitations of the managed app, e.g., based on enterprise securitypolicy. While the policy files may be optionally received as separatefiles, the policy files may be received as part of a same communicationor installation process as the managed app.

In step 1405 the mobile device executes the managed app in accordancewith the policy files. That is, the mobile device security manager (orequivalent process) restricts operations of the managed app as definedby the one or more policy files. In step 1407, during operation of themanaged app and based on one or the policy files, a data sharing featureof the managed app may be restricted, that might otherwise have beenallowed had the policy file(s) not been enforced. Various examples ofsuch data sharing restriction are provided in more detail below, as maybe used in accordance with FIG. 14 and/or other processes describedherein.

5.a. Secure Cut & Paste

On modern operating systems such as iOS, Android and Windows, there is amechanism typically called the “pasteboard” or “clipboard” that is usedto share data between applications. The user can “copy” data from oneapplication into the clipboard, and then “paste” it from the clipboardinto a second application. One problem is that the data put into theclipboard is not secured in any way, and sometimes there is a need tosecure it such that only a defined set of managed applications can sharethis data, hiding it from other non-managed applications. Aspectsdescribed herein provide a mechanism for redirecting copy and pasteoperations to the parallel encrypted clipboard, that only managedapplications have access to.

In order to provide secure copy and paste functionality between a set ofmanaged applications, the circuitry redirects copy and paste operationsto a parallel secure clipboard. This parallel clipboard is hidden fromgeneral view by other applications (any app without the appropriatepolicy file), and all data written to it is encrypted. Only managedapplications know how to access this hidden, encrypted clipboard.

In addition, to allow the user to copy and paste data from insecureapplication to one of the managed applications, a synchronization methodmonitors the unsecure clipboard for changes, and writes the changes tothe secure clipboard as needed.

Conventional smart phones enable one application (or “app”) to copy datato a general clipboard, and then another app to paste that data from thegeneral clipboard into a workspace of the other app. For example, a usermay copy text from a webpage of a browser app into the generalclipboard, and then paste that text from the general clipboard into anemail message of an email app.

It should be understood that there are deficiencies to the method ofconventional smart phones and their approaches to handling data via thegeneral clipboard. In particular, the general clipboard provides an easyvehicle for exposing secure data. For example, suppose that a companywishes to restrict data sharing to a managed set of apps. Unfortunately,the user of a conventional smart phone is able to simply copy securedata from one app to the general clipboard and then paste that securedata from the general clipboard to another app and thus allowing thesecure data to escape.

In contrast to the above-described conventional smart phone whichenables a user to easily expose secure data via the general clipboard,an illustrative policy file may define a secure clipboard that may beused to share data out of a managed app. All managed apps using the samepolicy (namely, defining the same secure clipboard), would then be ableto share data, whereas unmanaged apps would not. Even further, twodifferent managed apps whose policy files defined different secureclipboards also would not be able to share data. Thus, herein describedare improved techniques for conveying data between secure applicationsrunning on an electronic mobile device via a secure clipboard. As usedherein, a secure clipboard may refer to a clipboard whose storagelocation is hidden, e.g., known only to those applications that arepermitted to access the secure clipboard, and/or encrypted, e.g., andonly those applications that are permitted to access the secureclipboard know or have access to the encryption/decryption keys. Thesecure clipboard may be defined only to a set of secure (or “managed”)applications running on the mobile device (e.g., via policies).Moreover, all data may be encrypted by the managed app writing the datato the secure clipboard, and then decrypted by another managed appreading the data from the secure clipboard thus preventing exposure ofthe data even if the location of the hidden clipboard is discovered. Thelocation and/or type of secure clipboard, as well as the encryptionused, may be defined in a policy file.

With reference to FIG. 15, one illustrative embodiment is directed to amethod of conveying data between secure applications running on theelectronic mobile device (e.g., as described above) which is performedin an electronic mobile device having (i) processing circuitry and (ii)memory. The method includes receiving in step 1501, by the processingcircuitry, a copy command; and encrypting in step 1503, by theprocessing circuitry and in response to the copy command, original datafrom a first secure application to form encrypted data. The methodfurther includes writing in step 1507, by the processing circuitry andin response to the copy command, the encrypted data to a secureclipboard residing in the memory to enable a second secure applicationin step 1509 to subsequently read and decrypt the encrypted data fromthe secure clipboard, the secure clipboard residing at a location of thememory which is different than that of a general clipboard residing inthe memory, the general clipboard being accessible by a set of unsecureapplications running on the electronic mobile device. Alternatively, instep 1509, the same managed app may read from the secure clipboard,e.g., to cut and paste from one location to another within the managedapp.

Other embodiments are directed to electronic systems and apparatus(e.g., mobile devices), processing circuits, computer program products,and so on. Some embodiments are directed to various processes,electronic components and circuitry which are involved in conveying databetween secure applications running on the electronic mobile devicewhich is performed in an electronic mobile device.

FIG. 6 shows an illustrative electronic mobile device 601 which issuitable for use in conveying data between secure applications. Theelectronic mobile device may include, among other things, a userinterface 603 for user input/output, memory 605 to store data, andprocessing circuitry 613. Examples of suitable mobile devices includesmart phones, tablet devices, electronic notebooks, or any other mobiledevice described herein. In the context of smart phones, variousspecific platforms are suitable for use such as those running iOSprovided by Apple Computer, Android provided by Google, and Windowsprovided by Microsoft, among others.

During operation, the electronic mobile device 601 responds to usercommands by performing operations such as launching applications,establishing connections to external devices (e.g., cellular calls, WiFiconnections, etc.) to exchange wireless signals, and performing usefulwork. Along these lines, the processing circuitry of the electronicmobile device runs a set of (i.e., one or more) unsecure applications,and a set of secure applications.

When the processing circuitry 613 runs an unsecure application, theprocessing circuitry is configured to access the general clipboard 607for copy and paste operations in a traditional manner. For example,while the processing circuitry runs a first unsecure application, theuser is able to copy data from the first unsecure application to thegeneral clipboard 607. Additionally, the while the processing circuitryruns a second unsecure application, the user is able to paste the copieddata from the general clipboard 607 into a workspace of the secondunsecure application.

However, as illustrated in FIG. 6, the secure applications 701, 703 areconfigured to access the secure clipboard 609. In particular, to performa copy operation using a secure application, the processing circuitryencrypts the data and then writes the encrypted data into the secureclipboard 609 (bypassing the general clipboard 607). Furthermore, toperform a paste operation using a secure application, the processingcircuitry reads data from the secure clipboard 609, and decrypts thedata before placing the decrypted data into the workspace of that secureapplication. Accordingly, the data is never exposed outside the secureapplications.

In some arrangements, the mobile device 601 and/or managed app isconfigured to synchronize secure clipboard 609 with general clipboard607 when a copy event occurs in an unmanaged app. Device 601 maytherefore be configured to also input data from the general clipboardinto the secure applications. According to one aspect, copying of datainto the general clipboard by an unsecure (unmanaged) applicationcreates a detectable copy event. When the processing circuitry runs asecure application that receives an indication of the copy event, theprocessing circuitry may read the data from the general clipboard,encrypt the data to form encrypted data, and write the encrypted datainto the secure clipboard. Accordingly, the data within the secureclipboard is now synchronized with the data in the general clipboard andthe secure application which has access to the secure clipboard may nowaccess the data from an unmanaged app by reading the data from thesecure clipboard.

In some arrangements, mobile device 601 equips different groups ofsecure applications to use different secure clipboards. For example, theprocessing circuitry may provide (i) a first memory address of thesecure clipboard and a first set of cryptographic keys to a first groupof secure applications, (ii) a second memory address to another secureclipboard and a second set of cryptographic keys to a second group ofsecure applications, and so on. Such deployment and configuration of thesecure applications may be effectuated via policies to groupapplications where the policies dictate a particular group, keys andsecure clipboard to each secure application.

Using the above described technology, illustrative aspects are directedto a system to prevent sensitive data from being shared outside of amanaged set of applications. A company may wish to restrict data sharingto this managed set of applications, allowing full bidirectional access,but also potentially allowing incoming insecure data, such as text froma webpage, to be copied into one of the managed applications.

Furthermore, in some cases a system administrator may choose to entirelydisable copy and paste functionality, either for a single application, agroup of applications, or all managed applications. This is achieved byadding appropriate enforcement criteria in the policy file.

Also, there may be a need to have multiple application groups, each withits own secure clipboard. This is achieved by using policies to groupapplications, and then provide each group with their own separate secureclipboard.

Using aspect described above, in some mobile devices copy and pastebetween managed applications is totally secured by using a secureclipboard. In addition, synchronization with an unsecure clipboardallows a user to copy and paste data from an unsecure app into a secureapp, but not vice versa. Copy and paste functionality can be completelyblocked based on policies set by a system administrator.

FIG. 44 illustrates an example of such a process. Initially, a managedapplication may be received and/or installed in step 4401 on a mobileelectronic device, such as a smartphone, tablet, laptop or the like. Instep 4403 the device may separately and/or distinctly receive one ormore policy files defining one or more operational and/or behaviorallimitations of the managed app, e.g., based on enterprise securitypolicy. While the policy files may be optionally received as separatefiles, the policy files may be received as part of a same communicationor installation process as the managed app.

In step 4405 the mobile device executes the managed app in accordancewith the policy file(s). That is, the mobile device security manager (orequivalent process) restricts operations of the managed app as definedby the one or more policy files. In step 4407, during operation of themanaged app and based on one or the policy files, a cut and pastefeature of the managed app may be restricted as described above, wheresuch cut and paste feature might otherwise have been allowed had thepolicy file(s) not been enforced. Various examples of such cut and pasterestriction as described above may be enforced.

5.b. Sharing Data Between Managed Apps

Additionally, depending on settings of particular policies, applicationswithin a set of managed applications can be constrained to exchangefiles and/or data only with other managed applications within the set.In some arrangements, API calls from a managed application areintercepted by injected (or wrapped) code which operates to ‘contain’the application. A particular policy is read, and the operationspecified by the API call is either blocked or allowed depending on thesettings in the policy. When the policy file has a record of allapplications in the set of similarly managed applications (e.g., basedon an application group identifier, an enumerated list of applications,or any other mechanism that identifies a discrete set of applications),the application, by reading the policy file, can test whether therequested operation of the API call involves an application inside oroutside the set, and allow or block activity accordingly. Thus, based onpolicy settings, movement of data can be restricted such that datawithin the set of managed applications is not comingled with dataoutside the managed set.

A process of intercepting an API call, consulting an application'spolicy, and allowing or blocking the operation specified by the API callbased on the policy can be carried out in a number of contexts. In oneexample, the above process can be applied for selecting a set ofapplications on the mobile device that can be used to open a file ordata element identified by a link or icon (e.g., using Open-In). Inanother example, the above process can be applied for copying data ordata objects from one application and pasting the data or data objectsinto another application (e.g., via a hidden, encrypted paste buffer).In yet another example, the above process can be applied for movingfiles into and/or out of a protected file vault. Essentially, anyoperation used to move data into and/or out of an application can makeuse of the above techniques.

According to another aspect, data sharing may be limited by the factthat a set of applications are included within a same management policy.According to an aspect, by managing enterprise applications on mobiledevices using policy files, an enterprise may allow users to accessenterprise applications from their own mobile devices. The enterpriseapplications securely coexist with the users' own personal applicationsand data, based on the defined policy. Enterprise mobile applicationsare specially created or adapted in such a way that they are forced tointeract with other applications and services on a mobile device throughrespective application policies. Each enterprise mobile applicationrunning on the mobile device has an associated policy through which itinteracts with its environment. The policy selectively blocks or allowsactivities involving the enterprise application in accordance with rulesestablished by the enterprise. Together, the enterprise applicationsrunning on the mobile device form a set of managed applications. Thepolicy associated with each of the managed applications may include arecord of each of the other managed applications. Typically, policysettings for interacting with managed applications are different frompolicy settings for interacting with other applications, i.e.,applications which are not part of the managed set, such as a user'spersonal mobile applications. Managed applications are typically allowedto exchange data with other managed applications, but may be blockedfrom exporting data to unmanaged applications.

In some examples, application policies of managed applications areconfigured to allow links and/or icons presented in one managedapplication to be followed or opened in another application only if theother application is also a managed application. For example, a managedemail application can be configured, through its policy, to allow anattachment to be opened in a managed PDF annotator. But the same managedemail application can be configured to prevent the same attachment frombeing opened in a PDF annotator that is not part of the managed set.

By constraining managed applications to interact on a mobile devicethrough enterprise-administered policies, the managed set ofapplications can thus be made to operate with other applications in themanaged set of applications, but can be prevented from operating withapplications that are not part of the managed set. Leakage of enterpriseinformation out of the managed set of applications can thus beprevented, as can be receipt of personal information into the managedset of applications.

With reference to FIG. 49, illustrative embodiments are directed to amethod of managing applications of an enterprise on a mobile device. Themethod includes in step 4901 installing a set of managed applications ofthe enterprise on the mobile device, wherein other applications areinstalled on the mobile device that are not part of the set of managedapplications. The method further includes receiving in step 4903 a setof application policies, wherein each of the set of managed applicationsis associated with a respective policy of the set of applicationpolicies. Each managed app is executed in step 4905 by the mobile devicein accordance with applicable policy file(s). The method still furtherincludes selectively allowing in step 4907 a first application of theset of managed applications to provide data to a second applicationinstalled on the mobile device, responsive to accessing a policy of thefirst application and reading an indication from the policy of the firstapplication that the second application is a member of the set ofmanaged applications, and selectively blocking the first applicationfrom providing data to a third application installed on the mobiledevice, responsive to accessing the policy of the first application andfailing to read an indication from the policy of the first applicationthat the third application is a member of the set of managedapplications.

Other embodiments are directed to computerized apparatus and computerprogram products. Some embodiments involve activity that is performed ata single location, while other embodiments involve activity that isdistributed over a computerized environment (e.g., over a network).

One improved technique for managing enterprise applications on mobiledevices allows users to access enterprise applications from their ownmobile devices, where the enterprise applications securely coexist withthe users' own personal applications and data. Secure data sharing isaccomplished by creating a managed set of applications that can sharefiles and/or data with one another, but are selectively prohibited fromsharing files and/or data with applications that are not part of themanaged set. Thus, two objectives are achieved: (1) data are preventedfrom leaking out of the managed set and (2) data are allowed to beshared among the applications within the managed set.

FIG. 8 illustrates an environment in which embodiments hereof can bepracticed. Here, a mobile device 810, such as a smartphone, tablet, PDA,and the like, has installed upon it various mobile applications. Themobile applications include a set 820 of managed applications 822, 824,and 826, and a personal application 830. In some examples, an enterprisemobility management (EMM) client 840 (e.g., client agent 404) is alsoinstalled on the mobile device 810, which provides policy managementservices. The EMM client 840 is configured to connect, e.g., via anetwork such as the Internet, with an EMM server 850, which typicallyincludes an authentication server 852 and an application store 854.

Each application in the set 820 of managed applications is associatedwith a respective policy. For example, application 122 is associatedwith a policy 822 a, application 824 is associated with a policy 824 a,and application 826 is associated with a policy 826 a. In some examples,the policies 822 a, 824 a, and 826 a are provided in the form of files,such as XML or JSON files, in which the respective policy is expressedas a set of key/value pairs. In an example, each policy 822 a, 824 a,and 826 a includes a record of all applications within the set 820 ofmanaged applications (e.g., an application group identifier, anenumerated list of applications, or any other mechanism to identify adiscrete set of applications).

Each of the set 820 of managed applications is specially designed oradapted for use with the enterprise. Some of the set 820 of managedapplications may be designed specifically for the enterprise. Others ofthe set 820 of managed applications are more widely used applications(e.g., available to the public) that have been specifically adapted foruse with the enterprise, e.g., as described above. One or more of theset 820 of applications may include injected code that enables theapplication to conform to a framework of the enterprise. The injectedcode can be compiled into the application using an SDK. Alternatively,the injected code can be applied as a wrapper around a general-useapplication, to adapt it for use with the enterprise. In general, theinjected code serves to divert API calls from the application to itsassociated policy, such that the policy can selectively allow or blockactivities specified by the API calls.

In typical operation, a user of the mobile device 810 starts the EMMclient 840, logs on to the EMM server 850 via the authentication server852, and accesses the application store 854. The user can then peruseenterprise applications available from the application store 854, selectdesired applications, and download them to the mobile device 810, wherethe downloaded applications are included in the set 820 of managedapplications. For each application downloaded, a corresponding policy isalso downloaded to the mobile device, and the policies of allapplications in the set 820 are updated to reflect all members of theset 820.

In an example, policies (e.g., 822 a, 824 a, and 826 a) are refreshedperiodically and/or in response to particular events, such as each timethe respective application is started and/or each time the user logsonto the EMM server 850. Policies can thus be adapted over time anddynamically transferred to the mobile device 810 from the EMM server850.

Depending on settings of the policies 822, 824, and 826, applicationswithin the set 820 of managed applications can be constrained toexchange files and/or data only with other applications within the set820. For example, API calls from the application 822 are intercepted bythe injected code of the application 822. The policy 822 a is read, andthe operation specified by the API call is either blocked or alloweddepending on the settings in the policy 822 a. Because the policy 822 ahas a record of all applications in the set 820 of managed applications(e.g., an application group identifier, an enumerated list ofapplications, or any other mechanism to identify a discrete set ofapplications), the application 822, by reading the policy 822 a, cantest whether the requested operation of the API call involves anapplication inside or outside the set 820, and allow or block activityaccordingly. Thus, based on policy settings, movement of data can berestricted such that data within the set 820 of managed applications isnot comingled with data outside the managed set (e.g., with application830).

In some examples, applications in the set 820 of managed applications onthe mobile device 110 can be assigned to different groups. In suchcases, policies (e.g., 822 a, 824 a, and 826 a) are updated to includerecords of groups and group members. The flow of files and/or databetween applications can thus be further restricted to members ofparticular groups. Providing different groups of mobile applicationswithin the managed set 820 can help to segregate applications handlinghighly sensitive data from those that handle less sensitive data.

The above-described process of intercepting an API call, consulting anapplication's policy, and allowing or blocking the operation specifiedby the API call based on the policy can be carried out in a number ofcontexts. In one example, the above process can be applied for selectinga set of applications on the mobile device 810 that can be used to opena file or data element identified by a link or icon (e.g., using OpenIn). In another example, the above process can be applied for copyingdata or data objects from one application and pasting the data or dataobjects in another application (e.g., via a hidden, encrypted pastebuffer). In yet another example, the above process can be applied formoving files into and/or out of a protected file vault. Essentially, anyoperation used to move data into and/or out of an application can makeuse of the above technique.

These techniques can apply not only to movement of data to otherapplications, but also to recording, pictures, printing, playback ofaudio, and other functions.

Operating system extensions may be obtained for the mobile device 810.One such operating system extension responds to a user pointing to alink or icon representing a data object, such as a file, by displaying alist of applications on the mobile device 810 that are capable ofopening that data object. An example of such an operating systemextension is “Open In,” which is available on iOS devices. Similarextensions are available for Android and Windows-based devices.

In an example, applications within the set 820 of managed applicationssupport the use of Open In, but the list of applications displayed foropening a selected data object is limited based on the policies of therespective applications. For example, the list of applications displayedwhen Open In is invoked from the application 822 can be limited, inaccordance with the policy 822 a, only to other applications in themanaged set 820. Thus, in this example, Open In lists only applicationsthat are both (1) within the managed set 820 and (2) compatible with thedata object.

On mobile operating systems, such as iOS, Android, and Windows 8, eachapplication runs in its own sandbox. These apps use a very high levelcontent sharing mechanism like Open In in iOS, Intents/activities inAndroid and Charms in Windows8. On a BYOD (bring your own device) mobiledevice, it will have a mix of managed and un-managed/personalapplications running on the device. Sharing data among the managed setof applications should be carefully managed as described herein.

5.c. Restrictions on Data Sharing

On some mobile operating systems like iOS, the file system is notcompletely exposed to the end user by design to hide complexity. Thefocus is rather on the applications and the data they handle. As aresult, there are many ways data can move in and out of the device.Thus, according to another aspect, a policy file may allow or disallowuse of one or more data export features provided by a mobile device,based on whether or not an app is enrolled in enterprise mobilemanagement (also referred to herein as EMM). Some data export examplesinclude Email, Cloud based file data services , browser, browser-basedapps, voice dictation, memory sharing, remote procedure calls, andcontent provider API access to stored data (contact lists, etc.).

One way to keep data moving only among managed applications, a policymay cause the Open In list provided to the application to be filtered byintercepting the call and presenting to the application only the set ofmanaged applications which can handle that particular file format, asdefined in the policy file(s) in use.

The same technique may be extended to the Mail To option where the URLscheme used for Mail To could be intercepted and presented with theoption of Mail To with only a managed mail application like CitrixMobile Mail. This way, even the managed applications can be forced toSave to only the managed data sharing applications, like pre-approvedcloud-based file sharing services.

In another example, a policy may cause a device to perform dictationblocking. Some devices provide a voice dictation system and/or avoice-based automated assistant (e.g., Siri on iOS devices), referred tocollectively as dictation. However, voice features often perform voicetranscription in the cloud, because the mobile device might not haveenough processing power to efficiently transcribe voice to text on thedevice. In a typical scenario, a user speaks a voice command or voicedictation, the device then sends a recording of the voice to an onlineserver or cloud-based transcription service via a network connection,and the transcription service returns a file with text representing thewords spoken by the user. The mobile device then takes some action usingthe text file as input or as a basis for the action.

Because the voice command is sent to a system external to the device, apolicy may disallow dictation based on one or more factors. Dictationmay be disallowed altogether when a device is enrolled in EMM, or whenthe device includes policy managed apps. In another example, dictationmight be disallowed or allowed only when one or more predefined apps(e.g., managed apps) are active, executing, and/or on-screen. In anotherexample. Dictation might be disallowed or allowed only when the deviceis in a predefined geographic area, as determined by on-board locationservices (e.g., GPS, triangulation, wifi tracking, etc.). Other factorsmay also or alternatively be used by a policy to determine whether ornot to allow dictation (or any other feature described herein).

In another example, content provider data access may be blocked based ona policy file. Content providers often provide a standard interface, orAPI, through which third party apps may gain access to structured datastored by the content provider. Examples may include contact lists,email headers, social graph data, or any other structured datamaintained by the service provider. Similar restrictions as describedabove may be placed on access to such structured data within a managedapp, to prevent unmanaged apps from gaining access to data in managedapps.

In another example, creation and/or execution of a received remoteprocedure call may be allowed or disallowed based on a policy fileand/or based on whether an app is a managed app, as described herein. Inyet another example, sharing of memory space between two applicationsmay be allowed or disallowed based on a policy file and/or based onwhether an app is a managed app, as described herein.

By using above interception and filtering techniques, data flow in andout of the device as well as on the device is limited to the managedsecure space. The same techniques can also be used with Android andWindows 8, based on policy definitions.

With reference to FIG. 45, a method for restricting data sharing is nowdescribed. Initially, in step 4501, a mobile device (e.g., device 302,402, etc.) is set up to have one or more managed apps, and one or moreunmanaged apps, e.g., by enrollment in EMM, by downloading apps from aApp store, etc., as described herein. As part of step 4501, the mobiledevice downloads any applicable policy files from server 406 providingenterprise services 308 including policy management services 370, andapplies said policy file(s). In step 4503, a user (or the mobile deviceitself) attempts to initiate a data export operation. In step 4505, themobile device makes a determination whether that particular data exportis allowed based on information in the policy file. If the dataoperation is not allowed, then in step 4507 the mobile device preventsthe data operation from occurring. If the data operation is allowed,then in step 4509 the mobile device allows the user (or app, asapplicable), to perform the data export operation.

Variations of the method shown in FIG. 45 may be used. For example, adata export operation may be allowed when data is requested to beexported from a managed app to another managed app, but disallowed whendata is requested to be exported from a managed app to an unmanaged app.In addition, steps may be reordered or combined. For example, a mobiledevice, upon application of a particular policy file, may automaticallycut off app or user access to certain types of data export operations.Thus, it may be an impossibility for the user to even request certaintypes of data export operations after application of a policy file. Thisscenario is contemplated as being within the scope of FIG. 45. That isstep 4503 may be optional insofar as a mobile device may block one ormore data export operations based on a policy file before a user or appeven requests that an unauthorized export occur.

In one illustrative use-case scenario, a user may wish to get a filefrom a cloud-based file sharing service, annotate it with an annotator(e.g., a PDF annotator), and pass it to the corporate email service.This may be accomplished by including the necessary apps in the managedset 820. But it is also necessary to prevent the file from going throughprivate email, or to pass for viewing to other apps that are not part ofthe managed set 820 (and therefore trusted), as described above.

In order to provide enhanced security, it is preferred to avoidcomingling of trusted (managed) apps and untrusted (unmanaged) apps, butcomingling depends on policy. An admin on the EMM server 850 can setpolicies for any task of managed application to allow/disallow features.It is possible that a policy could allow a user or app to export a filefrom a managed PDF annotator to an app outside the managed set 820, butthen control over the PDF file would be lost. Other circumventions mayalso be possible, with the understanding that allowing circumventiondecreases security.

An administrator may set the policies of the managed applications, withdefault settings being to contain data within the managed set 820 oftrusted apps as described herein. The policies may be dynamicallydelivered from the EMM server 850. However, exceptions can be provided,e.g., to allow content to leak out from the managed set 820, whenbusiness concerns dictate it. For apps that are not part of the managedset 820, there is no interference with normal activities, i.e., they maybe unrestricted.

6. MOBILE RESOURCE MANAGEMENT (MRM)

As described above, when a mobile computing device accesses anenterprise computer/IT system, sensitive data associated with theenterprise and/or enterprise-related software applications can becomestored onto the mobile device. Enterprise-related data can comprise anydata associated with the enterprise, such as, without limitation,product information, sales data, customer lists, business performancedata, proprietary know-how, new innovation and research, trade secrets,and the like. Because this information can be very sensitive, anenterprise may wish to safeguard such information.

Further, enterprises may wish to regulate how users use their mobiledevices. For example, enterprises may want some control over where themobile devices are used, which mobile device features can be used, whichsoftware applications can be installed and/or run on the devices, andthe like. Enterprises also have a need to control and implement remedialactions for users that violate their mobile device usage policies.

When users in the field experience problems with their mobile devices orcould benefit from information, data, software, or coaching on how toperform certain operations using the devices, it can be difficult forthe enterprise's IT support to provide highly effective assistance.Accordingly, there is a need for improved secure management andtechnical support of mobile devices associated with an enterprise. Thisis sometimes referred to as Enterprise Mobile Management (EMM).Enterprises may manage devices, applications, software, settings,features, remote tools, virtualized apps, etc. Management of any device,application, or accessible tool is also referred to herein as MobileResource Management (MRM).

Embodiments described herein address these and other concerns. Thepresent application discloses computer systems and methods for automatedor semi-automated management of mobile computing devices that access anenterprise computer network, such as access to computer-implementedresources of the enterprise. As used herein, an “enterprise” maycomprise substantially any type of organization, including, withoutlimitation, a for-profit business, partnership, corporation, and thelike, as well as non-profit businesses, organizations, groups,associations, educational institutions, universities, and any othergroup of individuals bound by a common purpose or goal. A “mobilecomputing device” can comprise any of a wide variety of devices, suchas, without limitation, a mobile phone, smartphone, personal digitalassistant, tablet computer, handheld computing device, and the like. Themobile devices managed by the disclosed system may, for example, includeor consist of mobile devices that run the Android™, IOS, or WindowsMobile operating system (or some subset thereof). As will be recognized,however, the architecture disclosed herein may be used with other mobiledevice operating systems, including operating systems that may bedeveloped in the future.

Individuals, entities, or groups of users that use mobile computingdevices to access the enterprise computer network are referred to hereinas “users.” Users can comprise members of the enterprise, such asemployees, partners, officers, etc. Alternatively, users can compriseindividuals or entities that are not members of the enterprise, butnevertheless have a need or reason to access the enterprise computernetwork. For example, users can be enterprise customers, suppliers, etc.

An “enterprise resource” may comprise a machine-accessible resourceassociated with the enterprise. Enterprise resources can comprise any ofa wide variety of different types of resources, including resources thatassist or enable users in the performance of the users' roles or dutiesassociated with the enterprise. For example, enterprise resources cancomprise raw data stored on non-transitory computer-readable storage,documents stored on non-transitory computer-readable storage, computerhardware (e.g., physical servers), software applications stored onnon-transitory computer-readable storage, macros for softwareapplications (e.g., word processor macros) stored on non-transitorycomputer-readable storage, electronic mail systems, workspaces, customerrelationship management (CRM) systems, document management systems,enterprise resource planning (ERP) systems, accounting systems,inventory systems, engineering tools, forms, style sheets, and manyother resources. Enterprise resources can be configured to be accessedand used by software applications installed and running on mobilecomputing devices.

FIG. 9 is a schematic illustration of an embodiment of a computer system910 associated with an enterprise, as well as one or more users 915 andmobile computing devices 920 associated with the enterprise. In thisexample, each mobile device 920 is assigned to one enterprise user 915,but alternatives are possible (e.g., multiple users 915 assigned to onedevice, and/or a single user assigned to multiple devices 920). Themobile devices 920 are preferably configured to communicate with theenterprise system 910 (also referred to herein as an “enterprisenetwork”) over a communication network 925. The communication network925 can comprise a wireless carrier network, the Internet, a wide areanetwork, a WIFI network, and the like. Hence, the network 925 cancomprise, for example, one or more wireless networks, one or more wirednetworks, or a combination of wired and wireless networks. Additionally,an enterprise system 910 can be configured to be accessed by non-mobilecomputing devices, such as desktop computers.

The enterprise system 910 preferably includes an external firewall 922and an internal firewall 924. Each firewall 922, 924 can comprise adevice or set of devices designed to permit or deny networktransmissions based upon certain criteria. The firewalls 922 and 924 cancomprise software stored on non-transitory computer-readable storage,hardware, firmware, or a combination thereof. The firewalls 922 and 924can be configured to perform basic routing functions. Embodimentsdescribed herein can cooperate with one or both of the firewalls 922 and924 or other devices of the enterprise system 910 to filter mobiledevices' access requests based on a set of gateway rules, in order toprotect the enterprise system 910 from unauthorized access whilepermitting legitimate communications to pass. As will be described infurther detail below, such access rules can be used to regulate accessbased on, e.g., mobile device properties, user properties, the specificenterprise resources 930 for which access is requested, or anycombination thereof.

The physical or logical subnetwork between the two illustrated firewalls922 and 924 can be referred to as the “demilitarized zone” (DMZ), oralternatively as a “perimeter network.” Typically, the DMZ contains andexposes the enterprise's external services to a larger untrustednetwork, usually the Internet. Ordinarily, the purpose of the DMZ is toadd an additional layer of security to the enterprise's local areanetwork (LAN); an external attacker only has access to equipment in theDMZ, rather than any other part of the enterprise network.

The illustrated enterprise system 910 includes a mobile devicemanagement system 926, a secure mobile gateway 928, and a“meta-application” 950, each of which is described in further detailbelow. The enterprise system 910 also includes enterprise resources 930logically positioned behind the internal firewall 924, illustrated asresources 1 to N. At least some of the enterprise resources 930 can beconfigured to be accessed and/or used by the mobile devices 920, such asby software applications installed and running on the mobile devices.

Referring still to FIG. 9, the mobile devices 920 can communicate withthe carrier network 925 via connections 942, such as cellular networkconnections and/or WIFI connections that ultimately connect to carriernetworks. A mobile device's enterprise access request can be sent to thesecure mobile gateway 925 via a connection 946, and the gateway 928 cansend the request to an enterprise resource 930 via an internalconnection 954. Further, the enterprise system 910 can use theconnections 942, 946 to send information back to the mobile device 920,such as data responsive to the device's enterprise access request.

In some embodiments, a software application on a mobile device 920 cancommunicate with an enterprise resource 930 through an applicationtunnel via connections 942, 944, and 952. Application tunnels aredescribed in further detail below. In the illustrated embodiment, themobile device management system 926 acts as a “tunneling mediator”within an application tunnel between the mobile device 920 (andtypically a specific application running on the mobile device) and theenterprise resource 920.

FIGS. 10 and 11 illustrate embodiments that are similar to FIG. 9,except that the mobile device management system 926 and meta-application950 are respectively located (completely or at least partially) in acloud computing system or environment 956 (“the cloud”). (In a hybrid ofthese two approaches, both the mobile device management system 926 andmeta-application 950 reside in the cloud.) A cloud computing systemtypically includes computing resources configured to implement a serviceover a network, such as the Internet. For example, a cloud computingsystem can include a plurality of distributed computing resources, suchas physical servers or other computing devices. With a cloud computingsystem, computing resources can be located at any suitable location thatis accessible via a network. A cloud computing system can store andprocess data received over a network, while being accessible from aremote location. Typically, a cloud computing system is operated by aservice provider that charges the enterprise, and other users of thecloud based computing system, a usage fee for using the system. Incertain embodiments, both the mobile device management system 926 andthe meta-application 950 are located at least partially in the cloud956. In the embodiment of FIG. 10, the cloud-based device managementsystem 926 can be configured to provide gateway rules to the securemobile gateway 928 via a connection 958, as described in further detailbelow. Further, a software application on a mobile device 920 cancommunicate with an enterprise resource 930 through an applicationtunnel via connections 942, 960, and 962, with the mobile devicemanagement system 926 acting as a tunneling mediator. In the embodimentof FIG. 11, the meta-application portion 951 located in the cloud 956can be configured to provide gateway rules to the secure mobile gateway928 via a connection 964, as described in further detail below. Themeta-application 951 (or its rules engine) may alternatively beincorporated into the mobile device management system 926, in which caseit may orchestrate the management of the mobile device management system926.

FIG. 12 is an embodiment similar to FIG. 9, with the secure mobilegateway 928 implemented in the firewall 922. In the embodiment of FIG.12, the secure mobile gateway 928 can be implemented in a ThreatManagement Gateway (TMG) server. As illustrated in FIG. 12, someembodiments of the enterprise system 910 can be implemented without aninternal firewall 924.

FIG. 13 is an embodiment similar to FIG. 9, with the secure mobilegateway 928 implemented in an enterprise resource 930. In the embodimentof FIG. 13, the secure mobile gateway 928 can be implemented in anInternet Information Services (IIS) server. Such an IIS can beconfigured as an enterprise resource 930 and/or an internal firewall924.

It will be understood that any of the enterprise systems 910 can beimplemented with any of the principles and advantages described herein,as appropriate. Moreover, it will also be understood that the enterprisesystems illustrated in FIGS. 9-13 are provided for illustrativepurposes, and other suitable systems can be implemented in accordancewith the principles and advantages described herein.

FIG. 16 is a schematic illustration of an embodiment of the mobiledevice management system 926 of FIG. 9. The mobile device managementsystem 926 can comprise a system of one or more computers, computerservers, storage devices, and other components. As explained in greaterdetail below, the mobile device management system 926 can be configuredto manage or co-manage the application of “mobile device rules” 1614 tothe mobile computing devices 920, and/or to act as a “tunnelingmediator” between the mobile devices 920 and the enterprise resources930 during use of application tunnels therebetween. The mobile devicemanagement system 926 can also be configured to regulate mobile deviceaccess to the enterprise system 910, such as during use of suchapplication tunnels. The illustrated components of the system 926 aredescribed below.

FIG. 17 is a schematic illustration of an embodiment of a mobilecomputing device 920. The mobile device 920 can include a number ofordinary or standard components of a mobile device, such as a powersupply 1701, a processor 1702, a user interface 1704, a hard drivememory 1706, a memory card (e.g., Secure Digital (SD) card) port 1707, arandom access memory 1708, a network interface 1710, a subscriberidentification module (SIM) card port 1712, a camera 1714, and/or a GPSchip 1716. The implementation and use of these components is generallywell known and is not discussed herein in significant detail. The powersupply 1701 can include a battery port, battery, and/or a port forreceiving electrical power from an external source (e.g., a standardelectrical outlet). The processor 1702 can be configured to executesoftware applications and various other executable components. The userinterface 1704 can include any of various known components, such as akeypad 1724 (such as a set of physical buttons or, alternatively, atouchscreen keypad) for receiving text input, a screen or display 1726(which can be a touchscreen) for displaying text, images, and/or video,a speaker 1728 or audio out port for producing audible output, and/or amicrophone 1730 for receiving audible input. The hard drive 1706 cancomprise any of a variety of different types of nonvolatile and/ornon-transitory computer-readable storage. The memory card port 1707 isconfigured to receive a memory card (e.g., an SD card) on which data canbe stored. The random access memory 1708 can be used to store data usedduring the running of various processes. The network interface 1710 canbe used to send and receive data over a network (e.g., the wirelessnetwork 925, which can operate in accordance with a number of standards,such as Wi-Fi, 3G, 4G, etc.). The SIM card port 1712 is configured toreceive a SIM card, as known in the art. The camera 1714 can beconfigured to capture images and/or video. The GPS chip 1716 can beconfigured to process GPS signals. The mobile device 920 can furtherinclude one or more installed software applications 1718. The installedsoftware applications 1718 can be stored, for example, on the hard drive1706 or in non-volatile solid state storage. The installed applicationscan include both enterprise applications and personal applications. Itwill be appreciated that the mobile device 920 can include any othercomputer hardware components in place of or in addition to thoseillustrated in FIG. 3, such as an accelerometer, transceiver, batterycharger, USB controller, baseband processor, audio codec, etc.

In the illustrated embodiment, the mobile device 920 includes anenterprise agent 1720, which is preferably a software application orother executable program installed on the mobile device. The enterpriseagent 1720 is preferably separate from the operating system of themobile device 920. In some embodiments, however, the enterprise agent1720 can be a component of the operating system of the mobile device orpartially/fully embedded into the operating system of the mobile device920. In various embodiments described in greater detail below, theenterprise agent 1720 executes the mobile device rules 1614 andcooperates with the enterprise system 910 to regulate the mobiledevice's access to the enterprise system 910, including to theenterprise resources 930. In some embodiments, an enterprise system 910can prompt an enterprise agent 1720 to connect to the system 910 (e.g.,the mobile device management system 926) by sending a text message(e.g., SMS) to the mobile device 920, with a connection command.

The enterprise agent 1720 can be installed onto the mobile device 920 asa condition of the mobile device's enrollment with the mobile devicemanagement system 926. The enterprise can employ an automated subsystemfor installing enterprise agents 1720 onto the mobile devices 920associated (e.g., enrolled) with the enterprise. For example, a mobiledevice manager 1602 can be configured to send the enterprise agents 1720to the mobile devices 920 for automated installation or manualinstallation by the users 915. Alternatively, IT personnel can manuallyinstall the enterprise agents 1720 onto the mobile devices 920, or endusers can download and install the enterprise agent 1720 fromcommercially available application stores. Different types of enterpriseagents 1720 can be provided for different mobile device types,platforms, operating systems, etc. The mobile device manager 1602 oranother software component of the enterprise system 910 can beconfigured to select an appropriate enterprise agent 1720 for each givenmobile device 920, based on such properties of the mobile devices 920(e.g., mobile device properties 1608 of FIG. 16).

The enterprise agent 1720 may implement a variety of security-relatedfeatures, including features that control (or enable the control of)mobile device accesses to enterprise resources 930. For example, theenterprise agent 1720 installed on a given mobile device 920 may perform(e.g., instruct or cause the mobile device 920 to perform) some or allof the following tasks: (1) maintain a data connection with theenterprise system 910, which connection can be used both for applicationtunnels and for communications that do not involve application tunnels;(2) provide access to a public or private enterprise app store fromwhich the user can download enterprise applications that have beenapproved by and configured for the particular enterprise; (3) createapplication tunnels for enabling enterprise applications installed onthe mobile device to securely access certain enterprise resources, (4)collect, and transmit to the mobile device management system 926,“inventory” data regarding the properties and configuration of themobile device, such as its manufacturer, model, operating system, screensize, memory size, memory availability, GPS coordinates, and whichpersonal and enterprise mobile applications are installed on the device;(5) implement a log-in or other authentication service that requests andverifies the user's authentication information (e.g., passcode) when,for example, the user launches an enterprise mobile application; (6)decrypt encrypted message attachments received from the secure mobilegateway 928, such as encrypted attachments to email messages receivedfrom other members of the user's enterprise; (7) maintain a secure keystore that is accessible by enterprise applications for obtaining keysfor encrypting and decrypting data; (8) check for blacklisted mobileapplications installed on the mobile device, and report any suchapplications to the mobile device management system; (9) performprecautionary actions, such as deleting decryption keys used fordecrypting message attachments, when certain conditions are met, such aswhen a blacklisted mobile application is detected on the mobile deviceor the device is reported as stolen, (10) kill (terminate execution of)any blacklisted applications or other mobile applications determined tocreate a security risk, (11) provide one or more additional services forkeeping enterprise applications and data on the device separate frompersonal application and data; (12) ensuring that device-based securitymeasures are activated (e.g., keyboard/screen lock with passcode) and(13) wiping the device of all enterprise application and data (inresponse to a command received from the mobile device management system)when, for example, the user discontinues employment with the enterprise.As described below, some of these functions may alternatively beimplemented in a separate mobile application or component that isdistinct from the enterprise agent 1720.

The enterprise agent 1720 collects information about the mobile device'sconfiguration using standard operating system APIs and mechanisms,and/or using its own APIs and mechanisms. For example, inimplementations for the Android operating system, the enterprise agentmay query the package manager to obtain a list of the applicationsinstalled on the device. The enterprise agent can similarly query theoperating system for a list of mobile applications that are currentlyrunning, and can monitor broadcast messages to identify new applicationsthat are being installed. The device configuration information collectedby the enterprise agent through this process may be reported to themobile device management system 926, which may use the information togenerate rules that are applied by the secure mobile gateway 928 tocontrol the mobile device's accesses to enterprise resources 930. Theenterprise agent 1720 may itself also use the collected deviceconfiguration information to take various precautionary actions, such askilling blacklisted mobile applications as mentioned above.

In one embodiment, the enterprise agent 1720 is (or is part of) a mobileapplication that can be downloaded from an application store andinstalled on a mobile device 920. Once the enterprise agent has beeninstalled and launched, the end user supplies configuration information,such as a corporate email address and email password, for enabling theagent to communicate with a particular enterprise system 910. Onceconfigured, the agent 1720 provides the user access to a secureapplication store from which the user can download and installenterprise mobile applications that have been approved by, and in somecases specifically configured for, the user's enterprise. Thefunctionality for downloading and installing enterprise mobileapplications may alternatively be embodied within a separate “securelauncher” mobile application that runs in conjunction with theenterprise agent.

FIG. 18 illustrates some of the executable security-related components1750 that may be installed or implemented on a mobile device 920 with,or as part of, the enterprise agent 1720. As will be recognized, some ofthese components 1750 can be installed without others, and theillustrated components can be combined in various ways. One component isa key store 1750A that stores one or more encryption keys. In oneembodiment, the key store is implemented and managed by the enterpriseagent 1720, which enables the enterprise applications to access the keystore to obtain encryption keys. A given enterprise application may, forexample, use the encryption keys to encrypt files and other data storedto memory 1748.

With further reference to FIG. 18, a secure launcher 1750B may also beinstalled on the mobile device 920 for launching enterpriseapplications. The secure launcher may be part of the enterprise agent1720, or may be a separate mobile application. The secure launcher 1750Bmay implement or enforce various security policies, such as requiringuser entry of a valid passcode when an enterprise application islaunched. One embodiment of a user interface implemented by the securelauncher 1750B is shown in FIGS. 14 and 15 and is described below. Asdescribed below, enterprise applications may be modified or written touse the secure launcher rather than the general launcher included in themobile device's operating system. In one embodiment, the secure launcheralso includes functionality for wiping the mobile device 920 of allenterprise applications and data in response to a threshold number ofconsecutive invalid passcode entry attempts, or in response to aremotely issued command from the enterprise's IT department.

As further shown in FIG. 18, a secure virtual machine 1750C may beinstalled on the mobile device 920 in some embodiments to create oraugment a secure execution environment for running some or all of theenterprise applications. This secure virtual machine (VM) supplements,and may run concurrently with, the mobile operating system's default VM.For example, one or more enterprise mobile applications may run withinthe secure VM while all other mobile applications, including allpersonal mobile applications, run on the same device in the operatingsystem's default VM. As described below under the heading “SecureVirtual Machine,” the secure VM 1750C implements a variety of policiesand measures (such as security, management, storage, networking, and/orprocess execution policies) that are not implemented (or are implementedunsuitably for enterprise applications) in the mobile operating system'sdefault VM. For example, the secure VM may be capable of establishingapplication tunnels for accessing the enterprise system, and may routerequests from enterprise applications over corresponding applicationtunnels. The secure VM may also prevent an enterprise application fromrunning unless and until the user enters a valid passcode or otherwisesuccessfully authenticates. The secure VM may be installed on a mobiledevice together with a set of code libraries that are used by the secureVM in place of corresponding code libraries of the operating system.

One benefit of using a secure VM 1750C is that it reduces or eliminatesthe need for the mobile applications to be specifically written ormodified for use with an enterprise system 910. For example, anenterprise may wish to make a particular commercially-available mobileapplication available to its employees for use in accessing companyresources, but may not have permission to modify the application toimplement the various security features described herein (such asauthentication, secure storage, and secure networking). In such ascenario, the enterprise may configure the mobile application or themobile device to cause this particular application, when executed, torun only within the secure VM.

The secure VM is preferably implemented as a separate mobileapplication, but may alternatively be part of another application orcomponent (such as the enterprise agent 1720 or the secure launcher1750B). The secure VM may be invoked in various ways; for example, theenterprise agent may request that the secure VM run a particularapplication, or an application may, upon being launched, request orspecify the secure VM as it's execution environment. In someembodiments, the secure launcher 1750B and the secure VM 1750C are usedin combination to create a secure space for running enterpriseapplications, although each can be used independently of the other.Additional details of the secure VM are described below in the sectiontitled Secure Virtual Machine.

As further shown in FIG. 18, a secure container component 1750D may alsobe installed on the mobile device 920, preferably as a separate mobileapplication or as part of the enterprise agent 1720. This component1750D is responsible for creating a secure container on the mobiledevice for the enterprise applications to store documents and otherinformation. One embodiment of this feature is described below under theheading Secure Document Containers. In some embodiments, when aselective wipe operation is performed, some or all of the documents anddata stored in the secure container are deleted from the mobile deviceor are otherwise made inaccessible.

FIG. 18 also shows two types of mobile applications 1718 that may beinstalled on the mobile device 920: enterprise applications 1718A andpersonal applications 1718B. As illustrated, an enterprise application1718 may include executable security code 1760 (code libraries, etc.)for implementing some or all of the disclosed client-side securityfunctions (application tunnels, passcode verification, encryption ofdata, etc.) This security code 1760 may be added via a special SDK, ormay be added post-development via the application wrapping processdescribed below in the section titled Modifying Behaviors ofPre-Existing Mobile Applications. As mentioned above, in some cases agiven enterprise application may not include any security code 1760, butmay instead run within either a secure VM 1750C or a secure browser thatimposes a layer of security on the enterprise application.

In addition to the components shown in FIG. 18, one or more codelibraries may be installed on the mobile device for implementing varioussecurity functions, such as data encryption and formation of applicationtunnels. As one example, a custom SSL library may be installed and usedin place of the operating system's SSL library to create secureapplication tunnels, as described below in the section titledApplication Tunnels.

With reference to FIG. 46, according to one aspect, devices enrolled inMRM may be subject to different policies than those devices not enrolledin MRM. For example, a policy file may allow or disallow use of one ormore resources provided by or to a mobile device based on whether or notthe device (or an app) is enrolled in enterprise MRM (also referred toherein as EMM). Policy files may also be configured to restrict featuresbased on information learned from the MRM system. In step 4601 a policymanager may determine whether a device is enrolled in MRM. If the deviceis not enrolled in MRM, then in step 4603 the device's policy manager(e.g., client agent 404) applies a first policy file (or files). If thedevice is enrolled in MRM , then in step 4605 the policy manager appliesa second policy file (or files). The mobile device may subsequentlyrequest access to a resource, in step 4607. A resource may be a dataexport technique described herein or otherwise (e.g., memory sharing,URL dispatching, etc.), an external network service (e.g., fileshare,dictation, network access, etc.), or any other resource within oraccessible by the mobile device. In step 4609, the mobile device allowsor disallows access to the resource based on the policy file(s) in use.

When a user (e.g., an employee) executes a managed application on themobile device, the user is typically challenged to authenticate theuser's corporate identity along with passwords and other factors asdictated by corporate policy. After having authenticated the user anddevice, the access manager components of the system verify that the useris entitled to the application in question and downloads the policiesthat have been established by the enterprise administrator for this userwhen using this specific application. These application policies areusually cached and periodically refreshed to ensure compliance withadministrative settings. These policies may further restrict access tothe managed application only during certain times, from certainnetworks, form certain geo-locations, and only from devices that are incompliance with all organizations security policies.

By basing one or more policies on enrollment in MRM, or on informationlearned from enrollment in MRM, a policy can be based on information nototherwise known to the client agent 404, but which is known through theMRM service. For example, when enrolled in MRM, the MRM server storesinformation regarding whether or not a device has a device level PINenabled, device level encryption, security certificate information, andany other information that the MRM server has access to throughenterprise level management of the device. Thus, in the example of FIG.46, the second policy file, in one embodiment, may base a policydecision on whether or not the mobile device has a device level PINenabled. In another example, the second policy file may set a policybased on whether or not the mobile device has device level encryptionenabled. In another example, the second policy file may set a policybased on whether or not the mobile device has been provisioned with arequired certificate to access a particular enterprise resource. Forexample, an internal enterprise web site might require that the devicebe provisioned with a certificate from the MRM server. In addition, theconverse may also occur. For example, the MRM server may grant acertificate to a mobile device when an applicable policy file allows thedevice (or app) to access a particular resource that requires acertificate administered by the MRM server.

7. APPLICATION SPECIFIC POLICIES

According to some aspects of managed apps, a policy may be based on ortailored to a particular application or type of application. Forexample, a policy may be based on metadata associated with a particularapplication (originator, service description, version, etc.), or may bebased on information specific to that application, a feature offered bythat application, an application ID of the application etc. In such amanner, a policy may be tailored to a specific application orapplication type, e.g., web browsers, email, social networks, wordprocessing, spreadsheets, presentation, remote access, virtualization,etc. Policies may further be specific to a publisher of a specificapplication, e.g., INTERNET EXPLORER published by Microsoft may have afirst policy, whereas CHROME published by Google may have a secondpolicy. Alternatively, both INTERNET EXPLORER and GOOGLE CHROME might betreated with a same policy that applies to all web browser applications.Still further, a policy may define how other than a web browser mayexecute sub applications within an execution environment within the webbrowser, e.g., HTML5 applications, or how a remote access application,e.g., Citrix RECEIVER, might execute virtualized apps.

In still further aspects, policies may be industry specific. Forexample, all applications identified as associated with a financialservices industry might be subject to a first set of one or morepolicies; all applications identified as associated with a healthcareindustry might be subject to a second set of one or more policies; andall applications identified as associated with a legal industry might besubject to a third set of one or more policies. Individual policies mayoverlap, but the entire set to which each is subject may differ, asneeded. In still other aspects, policies may be location specific, evenwithin an industry or irrespective of industry. For example, ahealthcare app might be subject to a first set of one or more policieswhen the mobile device on which the app is running is determined to begeographically located within a first hospital (e.g., MassachusettsGeneral Hospital), and the healthcare app might be subject to a secondset of one or more policies when the mobile device on which the app isrunning is determined to be geographically located within a secondhospital (e.g., Brigham and Women's Hospital).

FIG. 50 illustrates an example of a process for managing apps using anapplication-specific policy file. Initially, a managed application maybe received and/or installed in step 5001 on a mobile electronic device,as described herein. In step 5003 the device may separately and/ordistinctly receive one or more policy files defining one or moreoperational and/or behavioral limitations of the managed app, e.g.,based on one or more features specific to the managed app. While thepolicy file(s) may be optionally received as separate files, the policyfiles may be received as part of a same communication or installationprocess as the managed app.

In step 5005 the mobile device executes the managed app in accordancewith the policy files. That is, the mobile device security manager (orequivalent process) restricts operations of the managed app as definedby the one or more policy files. In step 5007, during operation of themanaged app and based on one or the policy files, a feature of themanaged app may be restricted, that might otherwise have been allowedhad the policy file(s) not been enforced, where such feature is specificto the managed app and not included or possible with other managed apps.Various examples of such application-specific policy files are providedin more detail below, as may be used in accordance with FIG. 50 and/orother processes described herein.

Various aspects are described in more detail below.

7.A. Secure Web Browser Application

Another aspect of certain embodiments involves a web browser withinwhich other mobile device software applications can run. The web browsercan be provided with some or all of the enterprise security and otherfeatures described herein, and can extend those features for use withthe mobile device applications that run within the browser. In this way,the browser can be used to implement BYOD policies while maintaining adesired level of control over applications running on a mobile device920 of an enterprise user 915. An enterprise can require some or all ofits users 915 to install and use this web browser, to reduce enterprisesecurity risks associated with the use of such mobile deviceapplications. Further, in some circumstances, such a web browser canmake it unnecessary for application developers to develop differentversions of a mobile device application for different mobile deviceplatforms. As mentioned above, the secure browser can also be used toenable mobile device users to access a corporate intranet without theneed for a virtual private network (VPN).

Referring to FIG. 17, a mobile device 920 can include a specialized webbrowser 1732. The web browser 1732 can be configured to perform thefunctions of conventional web browsers, including surfing Internetsites, displaying and/or playing multimedia content received from webservers, etc. The web browser 1732 can store data accessed via a networkin a secure document container 1736 and/or in a secure browser cache.Such data can be deleted at the direction of an enterprise. Forinstance, a mobile device management system 926 can initiate deletion orotherwise make data stored in the secure document container 1736 and/orthe secure browser cache inaccessible. Additionally, the web browser1732 is preferably configured to act as a container for at least someother software applications 1718 installed on the mobile device 920, toallow those applications 1718 to run within the browser 1732. A softwareapplication 1718 can be configured to launch the browser 1732 when theapplication 1718 is itself launched by a user 915. Moreover, anapplication 1718 can be configured to launch the browser 1732 and runwithin the browser 1732 in a manner that is transparent to the user 915.In other words, the user 915 can be given the impression that theapplication 1718 is running conventionally, without involving the webbrowser 1732. The web browser 1732 can leverage a protocol thatfacilitates its usage as a container for other software applications1718. For example, the web browser 1732 can leverage HTML5 for thispurpose.

The web browser 1732 can provide some or all of the functionalitiesdescribed herein. For example, the web browser 1732 can include some orall of the functionalities provided by the SDK 2404 and/or enterpriseagent 1720 described above. Thus, the web browser 1732 can be configuredto use application tunnels for communications with network resources(such as enterprise resources 930). The web browser 1732 can receive (orhave embedded) mobile device rules 1614 and remedial actions 1616 fromthe mobile device management system 926 or another component of anenterprise system 910. The web browser 1732 can alternatively haveembedded mobile device rules and remedial actions. The web browser 1732can employ caching and/or compression methods within applicationtunnels, to improve the user's communication experience as describedabove. The web browser 1732 can be configured to provide credentials to,read from, write to, and/or provide an editor for displaying and editingdocuments obtained from a secure document container 1736 of the mobiledevice 920, as described above. In certain embodiments, the web browser1732 can implement the secure document container 1736. The web browser1732 can prompt a user 915 to supply access credentials prior and verifythe access credentials prior to exposing functionality of an application1718 running within the browser 1732 to the user 915. Alternatively oradditionally, the web browser 1732 can cause data stored to the mobiledevice 920 by an application 1718 running in the web browser 1732 to beencrypted. The web browser 1732 can be configured to participate in aremote control session with a helpdesk operator, as described above. Theweb browser 1732 can be configured to log fault detections, performancemeasurements, related events, event times, event locations, and otherdata, and to provide such data to an analytics service as describedabove in connection with the SDK 2404. The web browser 1732 can beconfigured to engage in communications with a meta-application, again asdescribed above. By providing at least some of these and/or otherfunctionalities, the web browser 1732 can make it unnecessary for mobiledevice application developers to embed such functions within the mobiledevice applications 1718.

In some embodiments, the web browser 1732 is configurable so that one ormore of these functionalities can be activated or deactivated underdefined conditions that can be configured, e.g., remotely by a remotecomputer system such as the enterprise system 910. Definable conditionsinclude temporal conditions, location conditions, mobile deviceproperties, user properties (e.g., roles 1606), and others. A temporalcondition can be the time of day. For example, the web browser 1732 canbe configured to force all mobile traffic (at least for applications1718 configured to launch the browser 1732) through application tunnelsonly during working hours (e.g., 8 am to 5 pm on Monday through Friday),and to send the traffic conventionally outside of those hours. Alocation condition can be the location of the mobile device 920. Forexample, the browser 1732 can be configured to activate theaforementioned compression and caching features when the device 920 isin a geographical area known to have bad wireless connectivity.

Different web browsers 1732 can be created for different mobile deviceplatforms, with each of the browser versions using a single standard forrunning mobile device applications. This can advantageously allow mobiledevice application developers to develop mobile device applications 1718in just one programming language, as opposed to creating differentversions for the various mobile device platforms. This can substantiallyreduce the application development workload for developers.

An enterprise can require its users 915 to install the web browser 1732onto their mobile devices 920, and can prohibit the use of other webbrowsers. The required browser 1732 can be configured to direct at leastsome of the mobile device traffic through application tunnels to anenterprise-controlled tunneling mediator, such as the mediator 1624described above. This gives the enterprise greater control over thetraffic, reducing security risks. An enterprise can deploy a mobiledevice rule 1614 that enables a device-resident enterprise agent 1720 orthe web browser 1732 itself to detect the installation and/or use of aprohibited web browser on the mobile device 920. An associated remedialaction 1616 can prevent the usage of the prohibited web browseraccording to methods described above, such as by uninstalling it,preventing it from running, etc.

In some embodiments, the secure web browser 1732 can be configured todirect some or all web surfing requests to a content-filtering server asdescribed above.

Other aspects of a browser' s operation may also be managed by policy,e.g., including but not limited to, URL filtering (whitelist/blacklist),customization of the presentation layer, bookmarks(preloading/configuration of bookmarks), start/home pages (presetting apage, preventing page changes, preventing page changes except by receiptof an updated policy file, etc.), download behavior (e.g., files inwhich downloads can be opened or from which a file can be attached intoa web apge), handling of specific types of URLs (e.g., mailto: to behandled by corporate email rather than gmail, etc.), handling ofspecific top level domains (e.g., .xxx, .onion, .mil, .us, etc.), and/orcontrol and configuration of runtime platforms such as HTML5, FLASH,Silverlight, .net, etc. (e.g., when embedded apps may be run, under whatconditions, storage locations accessible to each of different embeddedapps, etc.). Other characteristics may also be managed by policy files.

FIG. 51 illustrates an example of a process for managing a securebrowser app using an application-specific policy file. Initially, amanaged secure browser application may be received and/or installed instep 5101 on a mobile electronic device, as described herein. In step5103 the device may separately and/or distinctly receive one or morepolicy files defining one or more operational and/or behaviorallimitations of the managed secure browser app, e.g., based on one ormore features specific to the managed secure browser app discussedabove. While the policy file(s) may be optionally received as separatefiles, the policy files may be received as part of a same communicationor installation process as the managed app.

In step 5105 the mobile device executes the managed secure browser appin accordance with the policy files. That is, the mobile device securitymanager (or equivalent process) restricts operations of the managedsecure browser app as defined by the one or more policy files. In step5107, during operation of the managed secure browser app and based onone or the policy files, a feature of the managed secure browser app maybe restricted, that might otherwise have been allowed had the policyfile(s) not been enforced, where such feature is specific to the managedsecure browser app and not included or possible with other managed apps.Various examples of such application-specific policy files and featuresthat may be restricted/enforced are discussed above.

7.B. Secure Personal Information Management (PIM) Application

Another aspect of certain embodiments involves a personal informationmanagement (PIM) application, e.g., that includes email, calendar,contacts, notes, etc. The PIM app can be provided with some or all ofthe enterprise security and other features described herein, and canextend those features for use with the individual features of the PIMapp. In this way, the PIM app can be used to implement BYOD policieswhile maintaining a desired level of control over applications runningon a mobile device 920 of an enterprise user 915. An enterprise canrequire some or all of its users 915 to install and use this PIM app, toreduce enterprise security risks associated with the use of such mobiledevice applications. Further, in some circumstances, such a PIM app canmake it unnecessary for application developers to develop differentversions of a mobile device application for different mobile deviceplatforms. As mentioned above, the PIM app can also be used to enablemobile device users to access corporate services (e.g., email, calendar,etc.) without the need for a virtual private network (VPN).

Referring again FIG. 17, a mobile device 920 can include a specializedPIM application 1733. PIM app 1733 can be configured to perform thefunctions of conventional PIM apps, including providing email, calendar,contact, notes, journal, instant messaging, and othercommunication/collaboration services. PIM app 1733 can store data (e.g.,contacts, events, meetings, messages, etc.) accessed via a network in asecure document container 1736 and/or in a secure browser cache. Suchdata can be deleted at the direction of an enterprise. For instance, amobile device management system 926 can initiate deletion or otherwisemake data stored in the secure document container 1736 and/or the securebrowser cache inaccessible. Additionally, PIM app 1733 is preferablyconfigured to act as a container for at least some other softwareapplications 1718 installed on the mobile device 920, to allow thoseapplications 1718 to run within PIM app 1733 (e.g., add-ons,integrations, etc.). A software application 1718 can be configured tolaunch PIM app 1733 when the application 1718 is itself launched by auser 915.

PIM app 1733 can provide some or all of the functionalities describedherein. For example, PIM app 1733 can include some or all of thefunctionalities provided by the SDK 2404 and/or enterprise agent 1720described above. Thus, PIM app 1733 can be configured to use applicationtunnels for communications with network resources (such as enterpriseresources 930). PIM app 1733 can receive (or have embedded) mobiledevice rules 1614 and remedial actions 1616 from the mobile devicemanagement system 926 or another component of an enterprise system 910.PIM app 1733 can alternatively have embedded mobile device rules andremedial actions. PIM app 1733 can employ caching and/or compressionmethods within application tunnels, to improve the user's communicationexperience as described above. PIM app 1733 can be configured to providecredentials to, read from, write to, and/or provide an editor fordisplaying and editing documents obtained from a secure documentcontainer 1736 of the mobile device 920, as described above. In certainembodiments, PIM app 1733 can implement the secure document container1736. PIM app 1733 can prompt a user 915 to supply access credentialsprior and verify the access credentials prior to exposing functionalityas defined by an EMM service or policy. Alternatively or additionally,PIM app 1733 can cause data stored to the mobile device 920 to beencrypted. PIM app 1733 can be configured to log fault detections,performance measurements, related events, event times, event locations,and other data, and to provide such data to an analytics service asdescribed above in connection with the SDK 2404. PIM app 1733 can beconfigured to engage in communications with a meta-application, again asdescribed above. By providing at least some of these and/or otherfunctionalities, PIM app 1733 can make it unnecessary for mobile deviceapplication developers to embed such functions within the mobile deviceapplications 1718.

In some embodiments, PIM app 1733 is configurable so that one or more ofthese functionalities can be activated or deactivated under definedconditions that can be configured, e.g., remotely by a remote computersystem such as the enterprise system 910. Definable conditions includetemporal conditions, location conditions, mobile device properties, userproperties (e.g., roles 1606), and others. A temporal condition can bethe time of day. For example, PIM app 1733 can be configured to forceall mobile traffic through application tunnels only during working hours(e.g., 8 am to 5 pm on Monday through Friday), and to send the trafficconventionally outside of those hours. A location condition can be thelocation of the mobile device 920. For example, PIM app 1733 can beconfigured to activate the aforementioned compression and cachingfeatures when the device 920 is in a geographical area known to have badwireless connectivity, or in unsecure locations.

Different PIM apps 1733 can be created for different mobile deviceplatforms. An enterprise can require its users 915 to install PIM app1733 onto their mobile devices 920, and can prohibit the use of otherPIM app software. The required PIM app 1733 can be configured to directat least some of the mobile device traffic through application tunnelsto an enterprise-controlled tunneling mediator, such as the mediator1624 described above. This gives the enterprise greater control over thetraffic, reducing security risks. An enterprise can deploy a mobiledevice rule 1614 that enables a device-resident enterprise agent 1720 orPIM app 1733 itself to detect the installation and/or use of aprohibited PIM app on the mobile device 920. An associated remedialaction 1616 can prevent the usage of the prohibited PIM app according tomethods described above, such as by uninstalling it, preventing it fromrunning, etc.

In some embodiments, PIM app 1733 can be configured to direct some orall mail send/receive requests and/or events to a content-filteringserver as described above.

The above aspects, or other aspects, of a PIM app's operation may alsobe managed by policy, e.g., including but not limited to, addressfiltering (whitelist/blacklist autopopulation and/or prepopulation),customization of the presentation layer, address book contents(preloading/configuration of address book, conditions under whichcontacts may be exported, etc.), calendars to which the user has access,handling of specific types of URLs, files (e.g., URL dispatches),handling message attachments (e.g., defining which applications fromwhich a file can be attached; defining in which applications attachedfiles may be opened, e.g., .PDF to be handled by managed PDF viewerrather than open PDF viewer), control and configuration of add-ons,extensions, and/or runtime platforms such as HTML5, FLASH, Silverlight,.net, etc., control of message retention (duration, conditions, etc.,before automatic archive or deletion), and/or control of an automaticinstallation process for the secure mail/PIM app.

FIG. 52 illustrates an example of a process for managing a PIM app usingan application-specific policy file. Initially, a managed PIMapplication may be received and/or installed in step 5201 on a mobileelectronic device, as described herein. In step 5203 the device mayseparately and/or distinctly receive one or more policy files definingone or more operational and/or behavioral limitations of the managed PIMapp, e.g., based on one or more features specific to the managed PIM appdiscussed above. While the policy file(s) may be optionally received asseparate files, the policy files may be received as part of a samecommunication or installation process as the managed app.

In step 5205 the mobile device executes the managed PIM app inaccordance with the policy files. That is, the mobile device securitymanager (or equivalent process) restricts operations of the managed PIMapp as defined by the one or more policy files. In step 5207, duringoperation of the managed PIM app and based on one or the policy files, afeature of the managed PIM app may be restricted, that might otherwisehave been allowed had the policy file(s) not been enforced, where suchfeature is specific to the managed PIM app and not included or possiblewith other managed apps. Various examples of such application-specificpolicy files and features that may be restricted/enforced are discussedabove.

7.C. Client Agent/Virtualization Application Policies

Another aspect of certain embodiments involves a virtualizationapplication, e.g., a client agent such as CITRIX RECEIVER, and policiesspecific to such an application. The client agent can be provided withsome or all of the enterprise security and other features describedherein, and can extend those features for use with the individualfeatures of the client agent. In this way, the client agent can be usedto implement BYOD policies while maintaining a desired level of controlover applications running on a mobile device 920 of an enterprise user915. An enterprise can require some or all of its users 915 to installand use this client agent, to reduce enterprise security risksassociated with the use of such mobile device applications. Further, insome circumstances, such a client agent can make it unnecessary forapplication developers to develop different versions of a mobile deviceapplication for different mobile device platforms. As mentioned above,the client agent app can also be used to enable mobile device users toaccess corporate services (e.g., applications, desktops, servers, email,calendar, etc.) without the need for a virtual private network (VPN).

Referring again FIG. 17, a mobile device 920 can include a specializedclient agent 1720. Client agent 1720 can be configured to perform thefunctions of conventional client agents, e.g., remote access toenterprise resources. Client agent 1720 can store data accessed via anetwork in a secure document container 1736 and/or in a secure browsercache. Such data can be deleted at the direction of an enterprise. Forinstance, a mobile device management system 926 can initiate deletion orotherwise make data stored in the secure document container 1736 and/orthe secure browser cache inaccessible. Additionally, client agent 1720is preferably configured to act as a container for at least some othersoftware applications 1718 installed on the mobile device 920, to allowthose applications 1718 to run within client agent 1720 (e.g., as aremotely accessed application or virtualized application.). A softwareapplication 1718 can be configured to launch client agent 1720 when theapplication 1718 is itself launched by a user 915.

Client agent 1720 can provide some or all of the functionalitiesdescribed herein. For example, client agent 1720 can include some or allof the functionalities provided by the SDK 2404. Thus, client agent 1720can be configured to use application tunnels for communications withnetwork resources (such as enterprise resources 930). Client agent 1720can receive (or have embedded) mobile device rules 1614 and remedialactions 1616 from the mobile device management system 926 or anothercomponent of an enterprise system 910. Client agent 1720 canalternatively have embedded mobile device rules and remedial actions.Client agent 1720 can employ caching and/or compression methods withinapplication tunnels, to improve the user's communication experience asdescribed above. Client agent 1720 can be configured to providecredentials to, read from, write to, and/or provide an editor fordisplaying and editing documents obtained from a secure documentcontainer 1736 of the mobile device 920, as described above. In certainembodiments, client agent 1720 can implement the secure documentcontainer 1736. Client agent 1720 can prompt a user 915 to supply accesscredentials prior and verify the access credentials prior to exposingfunctionality as defined by an EMM service or policy. Alternatively oradditionally, client agent 1720 can cause data stored to the mobiledevice 920 to be encrypted. Client agent 1720 can be configured to logfault detections, performance measurements, related events, event times,event locations, and other data, and to provide such data to ananalytics service as described above in connection with the SDK 2404.Client agent 1720 can be configured to engage in communications with ameta-application, again as described above. By providing at least someof these and/or other functionalities, client agent 1720 can make itunnecessary for mobile device application developers to embed suchfunctions within the mobile device applications 1718.

In some embodiments, client agent 1720 is configurable so that one ormore of these functionalities can be activated or deactivated underdefined conditions that can be configured, e.g., remotely by a remotecomputer system such as the enterprise system 910. Definable conditionsinclude temporal conditions, location conditions, mobile deviceproperties, user properties (e.g., roles 1606), and others. A temporalcondition can be the time of day. For example, client agent 1720 can beconfigured to force all mobile traffic through application tunnels onlyduring working hours (e.g., 8 am to 5 pm on Monday through Friday), andto send the traffic conventionally outside of those hours. A locationcondition can be the location of the mobile device 920. For example,client agent 1720 can be configured to activate the aforementionedcompression and caching features when the device 920 is in ageographical area known to have bad wireless connectivity, or inunsecure locations.

Different client agents 1720 can be created for different mobile deviceplatforms. An enterprise can require its users 915 to install clientagent 1720 onto their mobile devices 920, and can prohibit the use ofother client agent software. The required client agent 1720 can beconfigured to direct at least some of the mobile device traffic throughapplication tunnels to an enterprise-controlled tunneling mediator, suchas the mediator 1624 described above. This gives the enterprise greatercontrol over the traffic, reducing security risks. An enterprise candeploy a mobile device rule 1614 that enables client agent 1720 todetect the installation and/or use of a prohibited application on themobile device 920. An associated remedial action 1616 can prevent theusage of the prohibited client agent according to methods describedabove, such as by uninstalling it, preventing it from running, etc.

In some embodiments, client agent 1720 can be configured to direct someor all mail send/receive requests and/or events to a content-filteringserver as described above.

Any of the above aspects, or other aspects, of a client agent'soperation may be managed by policy, e.g., including but not limited to,application filtering (whitelist/blacklist), differentiation ofaccess/authorizations based on whether an application is running localon a device or through a client agent app, customization of thepresentation layer, and/or address book contents (preloading allowableenterprise apps), to name a few.

Using any of the above features, one or more policy files may be adaptedto or created for applications running in a virtualization mode on amobile client device. The virtualization mode may include, for example,when an application is executing remotely from the mobile device (e.g.,remote access), but is presented to a user of the mobile device throughthe client agent software to appear as though the application isexecuting locally. Other types of virtualization may also be possible.The set of one or more policy files may restrict one or morecapabilities of the remotely executing application when the remotelyexecuting application is executing through the client agent than whenthe same application may be executing directly on the local mobiledevice. For example, the set of one or more policy files, when appliedby the mobile client device mobile device, might cause a managedapplication to operate using a different set of policy files when themanaged application is running in the virtualization mode on the mobileclient device, than when the managed application is directly executingon the mobile client device. In some examples, the set of policy filesmay automatically configure the managed application to run in thevirtualization mode. In other examples, the set of policy files mayrestrict cutting and pasting between applications executing directly onthe device with applications executing in the virtualization mode. Insome examples, applications running in virtualized mode might berestricted altogether from accessing a device clipboard and/or a secureclipboard (described above), based on one or more policy files. Thus,policy file(s) may be used to restrict one or more capabilities of anapplication executing remotely from the local (e.g., mobile) device.Such capabilities may include a general capability, such as access to aclipboard, or may include a capability specific to the applicationprogram, e.g., access to enterprise-specific modules within theapplication program. As one non-limiting example, a policy file mightrestrict user access to a set of enterprise-specific “shapes” inMICROSOFT VISIO when the application is executing through thevirtualization mode, whereas the user might have access to theenterprise-specific “shapes” when VISIO is executing locally on adevice.

According to an aspect, the set of policy files may apply only to aclient agent application capable of executing enterprise approvedapplications in the virtualization mode on the mobile client device.That is, policy files might apply to a client agent type of application,generically, which may include, e.g., CITRIX RECEIVER and otherapplications of the same genre. The policy files might then affect anyapplication accessed by or within the client agent application (e.g.,using a remote access mode), whereas a different set of policy filesmight be applied against other types of applications executing on themobile client device. The client agent application may serve as a sortof application “sandbox”, preventing malicious applications fromaccessing other areas of a mobile device.

In some examples, the policy files might define time-based or geographiclocation-based restrictions on access to enterprise resources throughthe client agent application. Different restrictions can be used foreach enterprise resource, or common restrictions might apply to multipleenterprise resources.

These are but a few examples, and any other type of restriction may beused that is controllable by a policy file as described herein. FIG. 53illustrates an example of a process for managing a client agent appusing an application-specific policy file. Initially, a managed clientagent application may be received and/or installed in step 5301 on amobile electronic device, as described herein. In step 5303 the devicemay separately and/or distinctly receive one or more policy filesdefining one or more operational and/or behavioral limitations of themanaged client agent app, e.g., based on one or more features specificto the managed client agent app discussed above. While the policyfile(s) may be optionally received as separate files, the policy filesmay be received as part of a same communication or installation processas the managed app.

In step 5305 the mobile device executes the managed client agent app inaccordance with the policy files. That is, the mobile device securitymanager (or equivalent process) restricts operations of the managedclient agent app as defined by the one or more policy files. In step5307, during operation of the managed client agent app and based on oneor more of the policy files, a feature of the managed client agent appmay be restricted, that might otherwise have been allowed had the policyfile(s) not been enforced, where such feature is specific to the managedclient agent app and not included or possible with other managed apps.Various examples of such application-specific policy files and featuresthat may be restricted/enforced are discussed above.

7.D. Modification of Unmanaged Applications into Managed Applications

A system and process will now be described for enabling non-developers,such as members of a company's IT department, to add to or otherwisemodify the behaviors of an existing mobile application, such as anAndroid, IOS, or Windows Mobile application, based on the specificapplication or type of application (e.g., an email application, browser,etc.). The system and process can be used, as one example, to createdifferent versions of a mobile application (with different privileges,access rights, etc.) based on a user's role within the enterprise. Forinstance, different versions of the mobile application can be createdfor different job categories (e.g., executive, non-executive employee,intern, etc.) and/or different departments (sales, IT, human resources,etc.). The processes described in this section can be implemented in anapplication modification or “wrapping” tool or utility that is madeavailable to enterprises that use the disclosed system. This utilitymay, for example, be hosted on a server (e.g., as a web service) that isaccessible to enterprises, or may be provided to the enterprises (e.g.,as a PC application).

In a typical use case scenario, the mobile application to be modified isa custom application developed for a particular enterprise. However,this need not be the case. For example, the disclosed system and processare also applicable to commercially available mobile applicationsavailable in app stores. The mobile applications can be modified withoutbeing specially written to support or enable such modifications. Forexample, the developer need not include any special code orfunctionality in the application to enable or facilitate themodifications, and need not be involved in the disclosed process ofmodifying the application.

The behaviors that are modified typically include or consist ofbehaviors that involve standard API calls or classes. The following areexamples of some of the types of behaviors that can be added or modifiedvia the disclosed process:

1. The cut-and-paste capability commonly provided through mobile deviceoperating systems, such as Android and IOS, can be disabled within aparticular mobile application, such as an application that providesaccess to confidential corporate data. This behavioral change may bedesirable to inhibit employees (or a certain class of employees) fromaccidentally or maliciously sending or moving confidential data to anunauthorized location.

2. A mobile application that stores its output in a non-encrypted formatcan be modified to store its output in an encrypted format. In oneembodiment, this is accomplished in-part by modifying the mobileapplication's input/output references to cause the application to use anencryption library to encrypt and decrypt the data it write to or readsfrom memory. Code may also be injected that causes the mobileapplication to obtain a key from the enterprise agent for use inencrypting and decrypting the data.

3. A mobile application that uses a certain level or type of encryptioncan be modified to use a different level or type of encryption. Forexample, if the Federal Government requires the enterprise to beginusing a particular encryption library, an existing mobile applicationcan be modified to effectively replace the existing encryption librarywith the new one.

4. An enterprise can modify a mobile application to cause it to use aspecial secure connection to the enterprise's network or enterprisesystem. For example, the mobile application can be configured to use asecure application tunnel as described above.

5. A mobile application can be modified to add a log-in or otherauthentication prompt or screen.

6. A mobile application can be configured to log and/or report dataregarding its usage. This data may include, for example, the time andduration of use, the location (based, e.g., on GPS coordinates) of use,the application features invoked, the access points accessed, etc.(Existing mobile device operating systems such as Android and IOSprovide functionality for enabling applications to obtain these andother types of usage parameters). This usage data may be used by anenterprise to, for example, monitor employee compliance with theenterprise's usage restriction policies, to identify and correctproblems with particular enterprise mobile applications, or to determinewhether to continue paying for application licenses for particularusers. The application usage data collected on a mobile device 920 may,for example, be reported by the enterprise agent 1720 to the mobiledevice management system 926, or some other system, for analysis.

7. A mobile application can be modified to enable an enterprise toremotely initiate deletion of the application's data on a particularmobile device 920 of a particular employee, without affecting otherusers of the application. As mentioned above, such selective wipeoperations may also be executed when, for example, a user fails to entera valid enterprise passcode a threshold number of times.

8. A mobile application can be modified such that it can only belaunched in by a secure launcher 1750B (FIG. 18), and not by the generallauncher of the mobile device's operating system. This may beaccomplished by, for example, changing one or more references in themobile application to the mobile operating system's general launcher sothat they point instead to the secure launcher. As explained above, thesecure launcher may implement one or more security policies, such asrequiring entry of a valid passcode before the enterprise application islaunched. The secure launcher may also cause the enterprise applicationsto run in a secure execution environment, such as by causing theenterprise applications to be executed using a secure virtual machine(FIG. 18) that is separate from the mobile operating system's virtualmachine. (See section below.)

9. A mobile application can be modified to cause it to launch in asecure virtual machine 1750C (FIG. 18). This may be accomplished by, forexample, modifying a reference in the application (e.g., in an Androidapplication's manifest or in any manner in which the application islaunched) to cause it to be launched in a secure VM. As explained belowin the section titled Secure Virtual Machine, the secure VM mayimplement some of the client-side security functions described herein(encryption, application tunnels, etc.), reducing or eliminating theneed to add such functions to the mobile applications themselves. Thiscan enable enterprise applications to be run in a secure executionenvironment, while personal applications are run in a default VM.

Other examples include disabling offline access, adding URL filtering,adding API filtering, disabling writes to local storage, and preventingdocuments from being opened in new applications.

FIG. 19 illustrates one embodiment of the application modificationsystem. According to this aspect, the system includes an applicationtransformer 1900 that makes the modifications based on operator-selectedpolicies. For example, after completion of the process described below,an application may be modified to operate under the control of one ormore policy files provided by an EMM. That is, the modifications do notnecessarily implement specific policies, but rather modify anapplication to be capable of running in accordance with one or more EMMpolicy files. In other aspects, an application's source code may bemodified, e.g., hard-coded, to permanently implement one or morerestrictions described above.

For Android applications, the transformer 1900 receives theapplication's .APK (application package) file, and outputs a new .APKfile representing the modified application. For IOS, the transformer1900 receives a IPA (iPhone application archive) file, and outputs a new.IPA file representing the modified application. Various other fileformats and mobile device operating systems may be supported. As shownin FIG. 19, the application transformer 1900 preferably includes adisassembler 1900A (for disassembling the application's executablecode), a code analyzer/mapper 1900B, a code modifier/injector 1900C, andan application rebuilder 1900D.

As shown in FIG. 19, the transformer 1900 accesses a policy library 1902containing policy descriptions for various policies and associatedbehaviors, such as those listed above. For example, a “disablecut-and-paste” policy may be provided. The policies may be described inany appropriate language and format. For example, the policydescriptions may be stored as DEX or smali files. As further shown inFIG. 19, the system also includes a control interface 1904 or “console”that enables an administrator to select the policy or policies to beapplied to a given mobile application. The console 1904 may also includea tool for enabling administrators to define new policies. For example,a new policy could be defined that adds an authentication sequence,disables cut-and-paste, and causes all files to be stored in encryptedform. This policy could then be used as a basis for modifying multiplemobile applications.

In a typical use case scenario, a member of a company's IT departmentuses the control interface 1904 to: select a mobile application to bemodified, select the policy or policies to be applied, and initiate thetransformation process. The modified application is then distributed tothe relevant employees or other users (e.g., through a specialapplication store that is accessible through the enterprise agent, asdescribed above). This process may be repeated with different policyselections to create different versions of the application for differentusers. The policy library 1902 may, for example, include policy filesfor implementing some or all of the types of policies described above(and various others).

FIG. 20 illustrates a sequence of steps that may be performed bytransformer 1900 to modify an Android application based on a selectedset of one or more policies. A similar process may be used to transformapplications written for other operating systems, such as IOS andWindows Mobile. The entire process shown in FIG. 20 is preferably fullyautomated, meaning that no human intervention is required. In block2000, the .APK file is opened. As in known in the art, this filecontains various application components, such as the application'sexecutable code, images, XML files, a manifest, and other resources. Inblock 2002, the disassembler 1900A disassembles the application'sexecutable code to generate one or more textual smali files. As will berecognized, an intermediate language other than smali can be used toimplement the disclosed modification tasks.

In block 2004, the analyzer/mapper 1900B analyzes and maps theapplication code (in smali format) to generate information regarding APIcalls that will potentially be replaced. In block 2006, the relevant APIcalls are replaced with new API calls for implementing the selectedpolicy or policies. In addition, the associated code from the policylibrary 1902 is added. For example, if the cut-and-paste functionalityis being disabled, any API calls that are used by the application toaccess the operating system's cut-and-paste functionality may be removedor replaced.

As one example, a new version of the Java I/O File Input Stream(Java.io.FileInputStream) class may be generated, and all references tothe original class may be modified to point to this new version. The newversion may, for example, include code for encrypting and decryptingdata on file write and read operations, respectively.

In block 2008 of FIG. 20, additional code may be added, if applicable,to implement one or more features or behaviors that do not require thereplacement of any existing API calls. As one example, code may be addedfor enabling an authorized administrator to remotely trigger thedeletion, on a user-specific or mobile device specific basis, of theapplication's data stored on a particular mobile device. In thisexample, the code added in block 2008 would add functionality forreceiving and processing a message containing a command to perform sucha selective wipe or deletion operation.

To provide an additional layer of security, the portions of the codethat are modified in the preceding blocks may be obfuscated usingobfuscation methods and functions that are known in the art. The use ofobfuscation impairs the ability of others to reverse engineer thesecurity functions added to the application. Obfuscation may be appliedto the disassembled code (e.g., smali code), or may be applied at adifferent level.

In block 2010 of FIG. 20, the application's manifest (e.g.,AndroidManifest.xml) is modified, if necessary, to reflect the modifiedbehaviors. As one example, if the application is being modified to belaunched in a secure shell, the manifest would be modified to instructthe Android operating system to use the secure shell to launch theapplication. In some embodiments, this involves replacing a reference tothe operating system's general launcher with a reference to a securelauncher 1750B (FIG. 18). In block 2012, the modified smali code andmanifest, together with the other extracted application components, arecompiled into a new .APK file. In block 2014, this new .APK file issigned using a digital certificate.

Mobile applications written for the IOS operating system may be modifiedin a similar manner. Typically, such an application is distributed as anIPA file that includes an executable in Mach-O format, a P-list, andresources. Once the executable has been disassembled to produce ARMassembly code, it is mapped to identify classes to potentially bereplaced, and is then modified by: (1) identifying one or more specificclasses to be replaced, (2) adding/modifying the code to replace suchclass(es), (3) adjusting the class structure to reflect themodifications, so that each new class is a subclass of the originalcode, and (4) updating the references to point to the new class orclasses.

According to an alternative method, an IOS application may be modifiedusing limited external symbol substitution. A dynamically linked librarymay then be added to the application package before recertifying.Subsequently, when the application is executed (runtime) the dynamicallylinked library is initialized and API interception is accomplished as aresult. When using an SDK approach for delivering iOS framework code,the same library may be statically linked into the application during abuild process while a small number of relevant symbols may be overriddenby compilation directive. API interception may again occur at run timeby hooking and replacing system functions.

In some embodiments, the above-described process may be augmented withone or more tests for verifying that the mobile application to bemodified does not contain malware, or does not otherwise present a riskto enterprise security. One such test involves generating a hash of someor all of the application files, and then comparing this hash to libraryof hashes that are associated with known malware. If a match is found(indicating that the application likely includes malware), theapplication modification process may be terminated.

Another such test involves inspecting the API calls and URL requestsmade by the application to check for suspicious activity. Examples ofsuspicious activity include reading the personal contacts stored on thedevice, sending an email to a cloud storage service, and sendinglocation information without first requesting user permission. Based onthis analysis, a score (e.g., on a scale of 1 to 100) may be generatedthat represents the level of risk posed by the mobile application. Themodification process may be terminated if this score exceeds athreshold. The score may additionally or alternatively be included in areport that details the suspicious activity detected. The applicationmodification tool may, for example, output this report for review, andmay prompt the administrator-user to confirm or indicate whether themodification process should proceed.

The application modification system shown in FIG. 19 may, for example,be implemented on a server, personal computer, workstation, or othercomputer or system of computers within a company's enterprise system.Alternatively, the application modification system may be implemented asa hosted service that is accessible to corporate customers over theInternet. The various components 1900-1904 of the system may beimplemented as code modules that are stored on any type(s) ofnon-transitory computer storage device or system.

The components 1900, 1902, 1904 of the system shown in FIG. 19 may beprovided to companies as part of a larger system (such as the systemdescribed in other sections of this specification) for enabling thecompanies to manage mobile devices and to protect data accessed by suchdevices. For example, these components may be bundled and licensed withvarious other components described in this disclosure. Alternatively,the application modification system of FIG. 19 may be provided tocompanies as a standalone product, or as a system that is hosted by aservice provider and accessed over a network.

Using one or more aspects described above, a mail/email application maybe secured using application-specific policies. That is, one or morepolicies may apply to the mail app based on features provided by,within, or to the mail app. According to an aspect, a policy may definewhen to accept and/or deny a URL dispatch including a preformed mailmessage. According to another aspect, a policy may derive informationfrom a single sign-on server (SSO) (e.g., user ID, handle, etc.) toautoconfigure a mail application with out user interaction. In such ascenario, a mail application may communicate with a client agent 404,create a MicroVPN or tunnel to a network server 406, and then configureitself based on information received via the MicroVPN.

According to some aspects, mail facilities may be enabled and/or disablebased on a policy file. In one example, contact sharing may beenabled/disables based on policy. A user may be allowed to export acontact to other managed apps, but not to unmanaged apps. In addition, auser may be able to attach, open, view, access, use, and/or export anattachment only to, from or within other managed apps, and not beallowed to perform similar activities on or with an attachment using anunmanaged app.

According to another aspect, policies may be usable to define how longmessages are retained and when messages are deleted (e.g., based ontime, size, sender, recipient, etc.). Policies may also be used todefine storage

8. NETWORK AND DATA ACCESS

8.A. MicroVPN/Tunneling

FIG. 21 shows an electronic environment which enables an electronicmobile device to securely access a computerized resource via per-apppolicy-controlled VPN tunneling. The cloud represents a communicationsmedium (e.g., a wireless computer network, the Internet, a cellularnetwork, combinations thereof, and so on) which enables the electronicmobile device to communicate with the remote access point.

FIG. 22 shows particular details of the electronic mobile device of FIG.21. As shown, the electronic mobile device includes, among other things,a user interface for user input/output, memory to store information, andprocessing circuitry. Examples of suitable mobile devices include smartphones, tablet devices, electronic notebooks, and so on. Furthermore,various specific platforms are suitable for use such as those runningiOS provided by Apple Computer, Android provided by Google, and Windowsprovided by Microsoft are suitable.

During operation, the mobile device builds per-applicationpolicy-controlled VPN-style connections between the specificapplications and a remote access point (e.g., a VPN server, a gateway,an individual computer, etc.). In particular, each specific application(i.e., a specially configured trusted application) is capable ofcoordinating operation with the specialized network software so that anapplication specific tunnel is constructed between that specificapplication and the remote access point.

FIG. 23 shows a flowchart of a procedure which is performed by theprocessing circuitry of the mobile device when operating in accordancewith various software constructs stored in the memory of the mobiledevice. In particular, the procedure enables the mobile device to accessa computerized resource via an application specific tunnel.

A variety of authentication techniques may be employed in the procedureabove. For example, in some arrangements, a set of tickets (or tokens)is loaded into the mobile device during initial authentication. Suchtickets may be one-time use and/or time-based, and impose constraints tocertain applications, resources and/or privileges (e.g., short-lived vs.longer-lived access).

During authentication of the user to the remote access point, suchtickets are offered in order to authenticate the user in a transparentmanner. That is, one or more tickets are provided from the mobile deviceto the remote access point in an effort to avoid burdening the user tore-authenticate. Nevertheless, it should be understood that over time,such tickets may expire. If such tickets expire prior to use, operationsthat required tickets instead now require that the user re-authenticate.

In some arrangements, access control is structured so that the level ofsecurity diminishes over time. For instance, some tickets which enablehigh security may expire first (e.g., after a predefined amount of timesuch as an hour, 15 minutes, etc.). Other tickets which enable lowersecurity may expire at a later time (e.g., after a later predefinedamount of time such as a day, etc.). Other ticket-based techniques forimposing different levels of security based on time are suitable for useas well.

Enterprises may be increasingly interested in developing nativeapplications for popular mobile device platforms such as iOS, Android,and/or Windows phones and tablets. One of the requirements for suchapplications may be the need for enterprise developed applications to beable to access the corporate intranet from wherever the device and usermaybe.

Many mobile resource management (MRM) solutions (also referred to hereinas EMM) offer a virtual private network (VPN) solution as the mechanismfor providing such access. However, traditional VPNs have the downsidethat all applications running on the mobile device are granted uniformaccess to the corporate intranet. Increasingly, mobile devices used toaccess enterprise resources are employee owned and not enrolled with anEMM server, and therefore not tightly controlled or managed by acorporate IT department. As such, there is a real risk of malware andother unauthorized software running on an employee's own mobile deviceto gain access to the corporate intranet when using traditional VPNsoftware.

Some forms of EMM seek to manage an entire mobile device. This is oftenreferred to as Mobile Device Management (MDM). Unlike MDM, a MobileApplication Management (MAM) solution seeks only to manage theenterprise applications and their associated data which may be installedand running on an employee's mobile device. Such systems generally userole based access to provision specially prepared enterprise apps thatare specifically designed to protect corporate assets. Such applicationsmay be policy controlled by an enterprise administrator and oftenrequire the employee to logon to corporate servers in order to accessthe managed applications.

Access to corporate servers is not a problem when the mobile device isconnected directly to a private corporate wireless network or LAN. Butwhen the employee's device is connected to a foreign network such as3G/4G network, home-based WiFi, or other public access point,transparent network access to corporate intranet is problematic withouta VPN. However, because a system level VPN gives access to all themobile device applications uniformly, a better solution for a managedenterprise applications is a per-application VPN technology that can bepolicy controlled. In this case, VPN access is granted to specific usersand their specially prepared enterprise applications only based on eachemployee's role within the organization. Non-enterprise applicationswould have no awareness of or access to resources inside of thecorporate intranet through this per-application VPN connection.

An object of certain embodiments is to provide a method for speciallyprepared enterprise applications delivered and managed through anenterprise mobile application management system to utilize VPNtechnology for access to corporate intranet resources even when themobile device is connected to a foreign network outside the corporateLAN, and to do so with enterprise assigned policies that limit suchaccess to specifically designated mobile applications for specificallydesignated users based on their role within the organization.

Enterprises first create (or adapt) their native mobile applicationsusing tools and SDKs associated with the mobile application managementsolution they have chosen to deploy. Among other things, this step addssome specialized network software to an application such that it will becapable of making VPN-style connection through a corporate gatewaydevice after authenticating the user and application.

These specially prepared enterprise managed applications are thenuploaded into an enterprise app store for an organization's employees toperuse and choose to install based on their role within theorganization. Alternatively, such applications can be pushed directly tomobile devices for employees who have enrolled their device with acorporate EMM/MRM server, or may be downloaded/installed from anenterprise web site, email, public network storage, removable media,through other apps, etc.

When a user (e.g., an employee) executes a managed application on themobile device, the user is typically challenged to authenticate theuser's corporate identity along with passwords and other factors asdictated by corporate policy. After having authenticated the user anddevice, the access manager components of the system verify that the useris entitled to the application in question and downloads the policiesthat have been established by the enterprise administrator for this userwhen using this specific application. These application policies areusually cached and periodically refreshed to ensure compliance withadministrative settings. These policies may further restrict access tothe managed application only during certain times, from certainnetworks, form certain geo-locations, and only from devices that are incompliance with all organizations security policies.

Assuming policy compliance is established and an application ispermitted to run, when the managed application actually begins tointeract with the network API's, the specialized network software addedduring the application preparation stage checks the current policysettings to determine if network access should be permitted. Assumingthe mobile device is running on a foreign network and the enterpriseadministrator has permitted VPN access for this application for thisuser, then the specialized network software initiates a secureconnection to the corporate gateway device, authenticates the user usinga ticket or token linked to the same credentials that were previouslyused to logon and confirm entitlement. If such token/ticket has expired,then the user may be asked to authenticate again before allowing VPNaccess for the mobile application. After authenticating to the gateway,the specialized network software constructs a VPN tunnel through thegateway device to the actual intranet resource that the applicationseeks to access. However unlike other system level VPN solutions, thisVPN tunnel is only available for this specific application to use.

If network access policy dictates no network access, then specializednetwork software may cause the network APIs to fail to connect. If thenetwork access policy permits network usage but does not permit VPNaccess, then the network service calls are routed directly to the mobiledevice platform network services though the local network that thedevice is attached to rather than being tunneled back to the corporateintranet. Additional network policies can further constrain the range ofcorporate intranet servers that are accessible by IP address, domain orhost names, port/protocol, TCP/UDP, etc.

Traditional system level VPN solutions do not discriminate betweentrusted and untrusted applications. By building in a per-applicationpolicy-controlled VPN solution, enterprises can ensure that onlyauthorized applications for authorized users in specifically configuredaccess scenarios are able to access corporate intranet resources from aforeign network.

In addition, by adjusting policy files, an enterprise can make policydecisions regarding whether to allow a MicroVPN (also sometimes referredto as per app VPN), disallow a MicroVPN, or tunnel data from specificmanaged applications to and from the enterprise servers. Each MicroVPNand/or tunnel may use single sign-on (SSO) credentials to authenticate auser, and may vector communications through gateway server 406 toenterprise resources. Using the SSO credentials, an enterprise candetermine what certificates a user has or is entitled to, and mayrespond to certificate challenges accordingly. In addition, mobiledevice 404 and/or gateway server 406 may intercept network traffic basedon policy information and/or based on certificates associated with theuser/device, and/or may respond to authentication challenges by virtueof seeing network level conversation. In one example, the networktraffic may be intercepted at the mobile device end point and themanaged app may retrieve proper authentication cert (e.g., based onenterprise policy) and supply to the enterprise resource it tries toaccess.

The above-provided description may discuss particular operations of theapplications figuratively (e.g., as the applications performing theoperations). However, it is actually the processing circuitry of themobile device that may perform operations while executing theapplications.

8.B. Using a Secure Container to Control Access to Enterprise Resources

An improved technique for managing encrypted data vaults for storingdata on mobile devices includes directing read and write operations froman application running on a mobile device according to anenterprise-generated policy, specific to that application, whichdesignates an encrypted vault for the data specified by the read andwrite operations.

Referring back to FIG. 8, which shows an illustrative environment inwhich embodiments hereof can be practiced, a mobile device 810, such asa smartphone, tablet, PDA, and the like, has installed upon it variousmobile applications. The mobile applications include a set 820 ofmanaged applications 822, 824, and 826, which are managed by theenterprise, and a personal application 830, which is not managed by theenterprise. In some examples, an enterprise mobility management (EMM)client 840 is also installed on the mobile device 810. The EMM client840, also referred to herein as a “broker,” is configured to connect,e.g., via a network such as the Internet, with an EMM server 850, whichtypically includes an authentication server 852, an application store854, and a key server 856. An example of the EMM client 840 is a clientagent available for Citrix. An example of the EMM server 850 is agateway server 406 that provides access to enterprise resources and/orcloud resources.

The illustrated mobile device 810 also includes a shared data vault 842.The shared data vault 842 includes encrypted files and/or data objectsaccessible to each of the set 820 of managed applications. Encrypteddata vault 842 may also be referred to herein as a secure persistentstorage area.

Each application in the set 820 of managed applications is associatedwith a respective policy. For example, application 822 is associatedwith a policy 822 a, application 824 is associated with a policy 824 a,and application 826 is associated with a policy 826 a. In some examples,the policies 822 a, 824 a, and 826 a are provided in the form of files,such as XML or JSON files, in which the respective policy is expressedas a set of key/value pairs. In an example, each policy 822 a, 824 a,and 826 a includes a record of all applications within the set 820 ofmanaged applications, as discussed above.

In some examples, each application in the set 820 of managedapplications is also associated with a respective private applicationvault. For example, application 822 is associated with a privateapplication vault 822 b, application 824 is associated with a privateapplication vault 824 b, and application 826 is associated with aprivate application vault 826 b. Encryption keys for the privateapplication vaults 822 b, 824 b, and 826 b, as well as an encryption keyfor the shared vault 842 are obtained from the key server 856 on the EMMserver 850 and can be held temporarily within the mobile device.

Each of the set 820 of managed applications is specially designed oradapted for use with the enterprise. Some of the set 820 of managedapplications may be designed specifically for the enterprise. Others ofthe set 820 of managed applications are more widely used applications(e.g., available to the public) that have been specifically adapted foruse with the enterprise. Each of the set 820 of applications includesinjected code that enables the application to conform to a framework ofthe enterprise. The injected code can be compiled into the applicationusing an SDK. Alternatively, the injected code can be applied as awrapper around a general-use application, to adapt it for use with theenterprise. In the context of the improvements disclosed herein, theinjected code serves to divert API calls for reading and writing fromthe application to its associated policy, such that the read or writerequests are redirected to a designated secure vault in accordance withthe settings of the policy.

In typical operation, a user of the mobile device 810 starts the EMMclient 840, logs on to the EMM server 850 via the authentication server852, and accesses the application store 854. The user can then peruseenterprise applications available from the application store 854, selectdesired applications, and download them to the mobile device 810, wherethe downloaded applications are included in the set 820 of managedapplications. For each application downloaded, a corresponding policy isalso downloaded to the mobile device, and the policies of allapplications in the set 820 are updated to reflect all members of theset 820.

In an example, policies (e.g., 822 a, 824 a, and 826 a) are refreshedperiodically and/or in response to particular events, such as each timethe respective application is started and/or each time the user logsonto the EMM server 850. Policies can thus be adapted over time anddynamically transferred to the mobile device 810 from the EMM server850.

Depending on settings of the policies 822, 824, and 826, applicationswithin the set 820 of managed applications can be constrained toexchange files and/or data only with other applications within the set820. For example, API calls from the application 822 specifying filereads or writes are intercepted by the injected code of the application922. The policy 822 a is read, and the read or write operation specifiedis diverted to an encrypted vault (e.g., the private vault 822 b or theshared vault 842), depending on the settings in the policy 822 a.

In some examples, applications in the set 820 of managed applications onthe mobile device 810 can be assigned to different groups. In suchcases, policies (e.g., 822 a, 924 a, and 826 a) are updated to includerecords of groups and group members. The flow of files and/or databetween applications can thus be further restricted to members ofparticular groups. For example, each group may be provided with its ownshared vault 942. Providing different groups of mobile applicationswithin the managed set 820 can help to segregate applications handlinghighly sensitive data from those that handle less sensitive data.

The above-described process of intercepting an API call, consulting anapplication's policy, and allowing, blocking, or redirecting theoperation specified by the API call based on the policy can be carriedout in a number of contexts. In one example, the above process can beapplied for selecting a set of applications on the mobile device 810that can be used to open a file or data element identified by a link oricon (e.g., using Open In). In another example, the above process can beapplied for copying data or data objects from one application andpasting the data or data objects in another application (e.g., via ahidden, encrypted paste buffer). In yet another example, the aboveprocess can be applied for moving files into and/or out of a protectedfile vault, as described herein. Essentially, any operation used to movedata into and/or out of an application can make use of the abovetechnique.

FIG. 24 shows various features of the mobile device 2410 in additionaldetail. Here, the application 2422 (representative of any of theapplications of the managed set 820) issues read operations 2410 andwrite operations 2412 to persistent space on the mobile device 2410. Innon-managed applications, such read and write operations would typicallybe directed to the application's sandbox. Here, however, read and writeoperations are intercepted by the policy-aware interception layer 2420and directed to an appropriate encrypted vault. For read operations2410, the policy-aware interception layer 2410 inspects the type of datato be read and consults the policy 2422 a. If the policy 2422 aspecifies that the identified type of data is stored in the privateapplication vault 2422 b, the policy-aware interception layer 2420obtains the data from the private application vault 2422 b. However, ifthe policy 2422 a specifies that the identified type of data is storedin the shared data vault 2442, the policy-aware interception layer 2420obtains the data from the shared data vault 2442. The policy-awareinterception layer 2420 then decrypts the data (using an encryption keyfrom the EMM server 2450), and returns the data to the application 2422.

In the case of write operations 2412, the policy-aware interceptionlayer 2420 inspects the type of data to be written and consults thepolicy 2422 a. If the policy 2422 a specifies that the identified typeof data is to be stored in the private application vault 2422 b, thepolicy-aware interception layer 2420 encrypts the data and stores thedata in the private application vault 2422 b. However, if the policy2422 a specifies that the identified type of data is to be stored in theshared data vault 2442, the policy-aware interception layer 2420encrypts the data and stores the data in the shared data vault 2442.

Referring back to FIGS. 17-18, in some embodiments, a mobile device 1720can include a secure document container or secure storage area 1736,which can be referred to as a “vault” or as a “container.” As explainedherein, container 1736 can help prevent the spread of enterpriseinformation to different applications and components of the mobiledevice 1720, as well as to other devices. The enterprise system (whichcan be partially or entirely within the cloud) can transmit documents tothe devices 1720, which can be stored (e.g., by the enterprise agent1720) within the container 1736. The container 1736 can preventunauthorized applications 1718 and other components of the device 1720from accessing information within the container 1736. For enterprisesthat allow users to use their own mobile devices 1720 for accessing,storing, and using enterprise data, providing containers 1736 on thedevices 1720 helps to secure the enterprise data. For instance,providing containers 1736 on the devices 1720 can centralize enterprisedata in one location on each device 1720, and can facilitate selectiveor complete deletion of enterprise data from the device 1720.

As used in this context, a “document” can comprise any computer-readablefile including text, audio, video, and/or other types of information ormedia. A document can comprise any single one or combination of thesemedia types.

The secure document container 1736 can compose an application thatimplements a file system 1738 that stores documents and/or other typesof files. The file system 1738 can comprise a portion of acomputer-readable memory of the mobile device 1720. The file system 1738can be logically separated from other portions of the computer-readablememory of the mobile device 1720. In this way, enterprise data can bestored in secure document container 1736 and private data can be storedin a separate portion of the computer-readable memory of the mobiledevice 1720. The container 1736 can allow the enterprise agent 1720,mobile device applications 1718 and/or other components of the device1720 to read from, write to, and/or delete information from the filesystem 1738 (if authorized to do so). Deleting data from the container1736 can include deleting actual data stored in the container 1736,deleting pointers to data stored in the container 1736, deletingencryption keys used to decrypt data stored in the container 1736, andthe like. The container 1736 can be installed by, e.g., the agent 1720,IT administrators of the enterprise system, or the device 1720manufacturer. The container 1736 can enable some or all of theenterprise data stored in the file system 1738 to be deleted withoutmodifying private data stored on the mobile device 1720 outside of thecontainer 1736. The file system 1738 can facilitate selective orcomplete deletion of data from the file system 1738. For example, acomponent of the enterprise system can delete data from the file system1738 based on, e.g., encoded rules. In some embodiments, the agent 1720deletes the data from the file system 1738, in response to receiving adeletion command from the enterprise EMM system. In other embodiments,the data is deleted without the assistance of the agent 1720, forexample if an agent 1720 is not provided.

The secure document container 1736 can comprise an access manager 1740that governs access to the file system by applications 1718 and othercomponents of the mobile device 1720. Access to the file system 1738 canbe governed based on document access policies (e.g., encoded rules)stored in the documents and/or the file system 1738. A document accesspolicy can limit access to the file system 1738 based on (1) whichapplication 1718 or other component of the device 1720 is requestingaccess, (2) which documents are being requested, (3) time or date, (4)geographical position of the device 1720, (5) whether the requestingapplication 1718 or other component provides a correct certificate orcredentials, (6) whether the user of the device 1720 provides correctcredentials, (7) other conditions, or any combination thereof A user'scredentials can comprise, for example, a password, one or more answersto security questions (e.g., What is the mascot of your high school?),biometric information (e.g., fingerprint scan, eye-scan, etc.), and thelike. Hence, by using the access manager 1740, the container 1736 can beconfigured to be accessed only by applications 1718 that are authorizedto access the container 1736. As one example, the access manager 1740can enable enterprise applications installed on the mobile device 1720to access data stored in the container 1736 and to preventnon-enterprise applications from accessing the data stored in thecontainer 1736.

Temporal and geographic restrictions on document access may be useful.For example, an enterprise administrator may deploy a document accesspolicy that restricts the availability of the documents (stored withinthe container 1736) to a specified time window and/or a geographic zone(e.g., as determined by a GPS chip 1716) within which the device 1720must reside in order to access the documents. Further, the documentaccess policy can instruct the container 1736 or agent 1720 to deletethe documents from the container 1736 or otherwise make them unavailablewhen the specified time period expires or if the mobile device 1720 istaken outside of the defined geographic zone.

Some documents can have access policies that forbid the document frombeing saved within the secure document container 1736. In suchembodiments, the document can be available for viewing on the mobiledevice 1720 only when the user is logged in to the enterprise system.

The access manager 1740 can also be configured to enforce certain modesof connectivity between remote devices (e.g., an enterprise resource orother enterprise server) and the container 1736. For example, the accessmanager 1740 can require that documents received by the container 1736from a remote device and/or sent from the container 1736 to the remotedevice be transmitted through application tunnels, for example, asdescribed above. Such application tunnels can use the tunneling mediatorof the enterprise system. The access manager 1740 can require that alldocuments transmitted to and from the container 1736 be encrypted. Theenterprise agent 1720 or access manager 1740 can be configured toencrypt documents sent from the container 1736 and decrypt documentssent to the container 1736. Documents in the container 1736 can also bestored in an encrypted form.

The secure document container 1736 can be configured to preventdocuments or data included within documents from being used byunauthorized applications or components of the mobile device 1720 orother devices. For instance, a mobile device application 1718 havingauthorization to access documents from the container 1736 can beprogrammed to prevent a user from copying a document's data and pastingit into another file or application interface, or locally saving thedocument or document data as a new file outside of the container 1736.Similarly, the container 1736 can include a document viewer and/oreditor that does not permit such copy/paste and local save operations.Moreover, the access manager 1740 can be configured to prevent suchcopy/past and local save operations. Further, the container 1736 andapplications 1718 programmed and authorized to access documents from thecontainer 1736 can be configured to prevent users from attaching suchdocuments to emails or other forms of communication.

A mobile device application 1718 can be programmed to lookup and findthe secure document container 1736 (or a secure web browser 1732,described below, that includes the container 1736) as a resource of themobile device 1720. In certain embodiments, the application 1718 can runin a secure virtual machine separate from a virtual machine of anoperating system of the mobile device 1720. According to some otherembodiments, the application can run within the secure web browser 1732.An application 1718 can be programmed to write enterprise-related dataonly into the container 1736. For instance, the application's 1718source code can be provided with the resource name of the container1736. Similarly, a remote application (e.g., an enterprise resource 830)can be configured to send data or documents only to the containers 1736of one or more mobile devices 1720 (as opposed to other components ormemory locations of the devices 1720). Storing data to the container1736 can occur automatically, for example, under control of theapplication 1718, the enterprise agent 1720, or the web browser 1732. Anapplication 1718 can be programmed to encrypt or decrypt documentsstored or to be stored within the container 1736. In certainembodiments, the container 1736 can only be used by applications (on thedevice 1720 or remote) that are programmed to look for and use thecontainer 1736, and which have authorization to do so.

The secure document container 1736 can serve as a temporary repositoryfor documents and other files sent to the mobile device 1720. Remoteapplications can be configured to send documents to the container 1736(e.g., via application tunnels) on a onetime or periodic basis. Forexample, a sales-related enterprise resource 930 can be programmed tosend sales-related documents (e.g., most recent price sheets) everymorning to the containers 1736 of a team of users having sales-relatedroles (e.g., sales persons). The sales-related documents can havedocument access policies such that the documents will “self-destruct”(e.g., be automatically deleted from the container 1736—the deletionbeing performed by, e.g., the container 1736 itself or the enterpriseagent 1720) at a certain time or at the expiration of a time periodbeginning at a defined event (e.g., the user's opening of a document).Document distribution policy file(s) (e.g., encoded rules, as describedherein) can be provided (e.g., within the mobile device managementsystem) to control when and how remote applications (e.g., enterpriseresources) send documents to the containers 1736, to which users thedocuments are sent, what restrictions (e.g., temporal or geographicrestrictions) are placed on the use and availability of the documents(e.g., in the form of document access policies as described above), etc.

Remote applications that send documents to one or more secure documentcontainers 1736 of mobile devices 1720 can be configured to integratewith other repositories, for the purpose of sending documents from suchrepositories to the containers 1736. Such other repositories can bestored, for example, within the enterprise system (e.g., enterprisedocument repositories such as a Microsoft Sharepoint™ repository) or ina cloud computing system (e.g., a Box.net™ repository).

EMM solutions have traditionally taken the approach of managing entiremobile devices through mobile device management (MDM) servers.Increasingly EMM solutions are focusing on a mobile applicationmanagement (MAM) solution that seeks only to manage the enterpriseapplications and their associated data which may be installed andrunning on an employee's mobile device. Such systems generally userole-based access to provision specially prepared enterprise apps thatare specifically designed to protect corporate assets. Such applicationsoften require employees to logon to corporate servers in order to accessthe managed applications. Additionally, such applications may beassociated with policies established by an enterprise administrator tocontrol application access while also seeking to protect and controlinformation held by the application.

One of the biggest challenges in managing enterprise applications on anotherwise unmanaged mobile devices is ensuring that information used bythe managed application cannot escape from the set of trusted enterpriseapplications that IT administrators make available to their enterpriseusers. Information can escape in any number of ways, and a robust EMMsystem will provide policies and enforcement mechanisms to prevent suchinformation leakage where IT administrators deem it proper and toprovide policy overrides, where appropriate. However, even with a robustset of information containment policies, there are other threats to thesecurity of the information managed by applications on mobile devices.

One such threat is that applications may store some informationpersistently on the mobile device by writing files or other data intothe flash memory or other persistent storage on the device. Most mobileplatforms will segregate persistent data recorded by applications intoprivate application sandboxes. However this sandboxing is triviallydefeated with common tools capable of rooting or jail-breaking thedevice. Rooting and jail-breaking are techniques that seek to replaceparts of the mobile device operating system platform often with goal ofdefeating app sandboxing, app integrity checks, and other OS providedsecurity mechanisms. Rootkits and jail-breaking software for mostpopular mobile platforms are readily available on the public Internetand easy to use. Since rooting and jail-breaking are so easy toaccomplish, most enterprises do not wish to rely on mobile device OSenforced sandbox as the only means of protecting data that anapplication may need to persist.

Some mobile device platforms additionally allow information to beencrypted in its persistent form and some applications do take advantageof these features. Invariably, such encryption mechanisms rely on theencryption keys being held on the device itself with the keys themselvesprotected by a user supplied PIN or passcode. The fact that the keys areheld on the device and protected by weak cryptographic factors meansthat the data is not particularly well protected from hacking,particularly if a device is stolen and hacker has ample time to try tounlock the keys. Also, since the keys are in possession of the deviceholder, an enterprise is powerless to remove them or revoke access for aterminated employee unless they can recover the device.

Another issue with app sandboxing that occurs on mobile platforms isthat it is problematic to have a single repository of documents that areavailable to all managed applications on the mobile device andpotentially synced offline to cloud based storage. Mobile applicationswork around the sandbox limits in various ways, all of which havedrawbacks. Often, they will exchange files of certain fixed types withother applications that have registered to accept certain those sametypes. The drawback here is that one ends up with multiple copies of aparticular file in each app's sandbox. If one or more apps wish to editthe file content, keeping track of which app has latest versions isproblematic for users.

One can overcome the issue highlighted above if users are trained toalways send their modified documents back to a common sync agentapplication which might also be charged with syncing documents to/fromcloud based storage. Cloud-based file sharing service mobileapplications are an example of an application that permits this sort ofdata exchange with cloud-based sync. The drawback here is that theseextra steps are easy to forget. Also, they are not required when usingequivalent desktop applications that operate on the notion of shareddocuments folders for all applications. These two facts can lead to datafile consistency issues and poor user experience if users are notproperly trained.

Another approach to this problem is to save the files that one wishes toshare into shared storage on those mobile platforms that support thisconcept. This has the downside that shared storage is world readable andtherefore shared with all applications. Once information is placed intoshared storage, containment of the information is lost since anyapplication on mobile device can read it. Also the data can trivially beaccessed by anyone who gains physical access to the device usingstandard file viewers and development tools.

The challenges of information containment and sharing of documentsbetween trusted applications that are highlighted above are overcome byintroducing the concept of an encrypted file vault. An encrypted filevault is a logical container into which all persistent data read/writtenby a mobile application (which would otherwise end up in a writeablefile in the app sandbox) will be redirected. The contents of the vaultare themselves written into file(s) held inside an app sandbox. But thecontents of all files and the file metadata itself (name, size, accesstimes, etc.) are all encrypted.

Strong encryption algorithms (e.g. FIPS 140-2 certified) are used toprotect all information placed into the vault with keys that are managedby the enterprise rather than the users themselves. Keys would typicallybe assigned based on a tuple of user, device, and application or appgroup. That implies that distinct key sets are used each uniquecombination of user, device, and application/app group. The keys aremaintained off device in an enterprise key management server. The keysmay be downloaded temporarily to the mobile device to enable dataaccess, but only after strongly authenticating the user, device, andapplication in question.

An application may be written in such a way that it is aware of thepresence of file vault services. Applications written with thisawareness can utilize any number of file vaults, which they can identifyexplicitly with vault name identifiers. However applications will notalways be written with such awareness. Correspondingly, administratordefined policies can be used to configure a default file vault for eachapplication. The default file vault of an application is used for thetransparent redirection of all application file I/O that would otherwiseend up in a writable portion of the application sandbox or sharedstorage.

The typical mechanism for assigning apps to a default file vaultdictates that the administrator place each configured mobile applicationinto a named security group by policy. Then all applications that sharethe same security group inherit the same default file vault. In thismanner, applications not only gain the security of the encryptedcontainer for their data, but apps configured with the same default filevault will see a single consistent view of their data shared with othersimilarly configured file applications.

It should be noted that not all writable areas in the app sandbox areappropriate for sharing with other applications, for example theapplication's /tmp directory. The implication here is that there isalways an app private file vault that would be used to hold certainfiles and directories. If the app is not configured into a shared group,then all files are redirected to the app private vault. However if anapp were configured into shared group, documents and other such fileswould be redirected to the common vault but files designated for specialprivate directories like /tmp would continue to flow to the app'sprivate vault.

It should also be noted that the notion of a shared file vault doesimply the existence of a common broker that manages the shared files onbehalf of all applications. Without such a broker, one would not be ableto share files transparently. While such a broker could be anetwork-attached service that does not exist on the mobile deviceitself, such a design would preclude offline access to the encryptedfile vault. For this reason, another application installed on the mobiledevice will generally serve this role. An EMM client agent like theCitrix client agent mobile application would be the typical host of thisshared vault broker.

The above-described technique thus offers the unique combination oftransparent file access, strong encryption with keys managed by theenterprise, and dynamic reconfiguration of the vaults by policy.

Enterprises may create (or adapt) their native mobile applications usingtools and SDKs associated with the enterprise mobility management (EMM)solution they have chosen to deploy. In preparing their app for EMMdeployment, they certainly have the freedom to (re)write specificapplication logic to utilize encrypted file vault services exposed bythe EMM developer SDK as needed for their application. However, mostoften, an application will already be written to use standard filesystem APIs of the platform for which they were developed. As such, itis far more convenient for the application developer if the EMM SDK andtools can transparently redirect these native file access services toone or more file vaults dictated by administrative policy rather thanrewriting their application. This approach also allows an administratorto reconfigure targeted file vaults without directly modifying andrecompiling the application.

When taking this approach, the application developer need not worryabout the specifics of how to interface with the native file vaultservices. Instead, by integrating the header files, libraries, andrun-time support of the EMM system framework code with the application,all file system APIs called by the application will be redirected to apolicy-aware interception layer. Assuming the encrypted file vaultfeature is configured, then based on the policies in force for thecurrent user, device, and app, a set of default file vaults will beselected and the file system API interception layer will be configuredto target them.

After preparing the application for the specific EMM system, the managedapplication is uploaded to the EMM server for the purpose of publishingthe application for the enterprise users to consume. As part of this apppublishing workflow, an IT administrator will choose policies andsettings that apply to the application and associated user roles. Onceuploaded and configured, the applications is made available toorganization's employees to peruse and install based on their rolewithin the organization. Alternatively, such applications can be pusheddirectly to mobile devices for employees who have enrolled their devicewith a corporate EMM server.

When a user executes a managed application on the mobile device, theuser is typically challenged to authenticate their corporate identityalong with passwords and other factors as dictated by corporate policy.After having strongly authenticated the user, device, and application,the access manager components of the system verifies that the user isentitled to the application and downloads the configured policies forthis specific app and user.

Based on those policies, the EMM framework that is delivered with themanaged app configures itself. It will select one or more default filevaults to use and configure the file system API interception layer totarget the selected vaults. If a configured file vault does not alreadyexist, a new empty vault is initialized. This ensures that a change infile vault policies that would select a not-previously-used vault willappear to the application as if it had been recently installed (e.g.empty writable directories).

As the application begins to utilize the file system APIs, the filesystem API interception layer looks for file accesses that intersect thewritable portions of the app sandbox or shared storage. Such files areflagged and tracked by the file system interception layer such that allsubsequent file I/O is passed through encryption/decryption before beingplaced into the real file container that holds the data.

In order to accomplish this encryption, the required keys first need tobe recovered. These are retrieved from the key management server andcached locally. If this is the first access to the protected files in along time, the user will be forced to do a strong authentication bylogging on to the EMM server. Periodically these keys will need to berefreshed as dictated by the time to live policy setting for the keys.When refreshing, as long as user has maintains an active logon with EMMserver, this refreshing of keys can occur without user interaction. Ifuser logs off or their logon session expires, then the refreshing ofkeys will need to be strongly authenticated again.

When the file vault is private to the application, the file vaultservices layer directly uses the mobile platform's file I/O functions toread and write encrypted version of the data. Also, all file directoryaccess functions are also similarly intercepted such that the real filenames and sizes can be obscured.

To support random access to any range of bytes within an encrypted file,a scheme that uses encrypted blocks is may be used. For this to work,the keys used to encrypt/decrypt each of the file block are derivedmathematically from base keys and the file/block offset. Similarly,different files will use initialization vectors for the cryptography aswell. These techniques represent sound and reasonably standard practicesfor the encoding encrypted file volumes using a single set ofcryptographic keys.

For efficiency, the system may read ahead or delay writing of data toencrypted data content as necessary to optimize application performance.Delayed write of encrypted data must be flushed prior to closing filesor exiting the application.

When the file vault is to be shared with another application, the sameprocesses described above are used, but they must occur in a common filesystem repository under the control of common file system brokerapplication. The implication is that when the file system interceptionlayer is operating on shared file vault, the file vault services willoperate not by directly reading/writing encrypted data, but rather byredirected these services via remote procedure call mechanism to thebrokering application. Within the brokering application, the same localfile vault services used for private vault files are utilized for theshared vault content.

There are other possible designs for implementing shared vaults. Forexample, one can use shared storage coupled with inter-processsynchronization mechanisms to coordinate access. But in any workabledesign, the key factor to be noted is that same underlying encryptedfile vault services are used to encrypt the actual file data regardlessof where the encrypted data will be retained or how concurrent access toit coordinated.

By providing strong and transparent file encryption services with keysmanaged by enterprise servers, security of information held and storedlocally by managed mobile applications can be made secure without theneed to rewrite applications to use new file access paradigms.

Adding the notion a policy directed file vault configuration thatpermits multiple applications to be bound to the same default filevaults further permits secure sharing of documents between properlyconfigured managed applications.

The architecture described herein can be used by a corporation or otherenterprise to flexibly implement a policy, such as a corporate owneddevice, BYOD (bring your own device) policy, for allowing enterpriseusers to use their mobile devices to securely access enterpriseresources (documents, confidential data, corporate application anddatabase servers, etc.). This is accomplished through various securityfeatures that, for example, enable the enterprise to specify andimplement policies for controlling mobile device accesses to particularenterprise resources. The policies may, for example, control mobiledevice accesses to enterprise resources based on a variety of criteria,such as the role of the respective user (e.g., which department the useris in), the configuration of the mobile device (e.g., whether anyblacklisted mobile applications are installed), the logged behaviors ofthe user, the location of the mobile device, and/or the time at whichaccess to the enterprise resource is requested. The architecture furtherenhances security, in some embodiments, by creating application tunnelsthat enable enterprise mobile applications to securely communicate overa network with the enterprise system. The architecture may also enableIT staff to selectively (and remotely) wipe a user's mobile device ofenterprise application(s) and corporate data when, for example, the userdiscontinues employment or violates a corporate policy (such as if theyjailbreak their device or otherwise use it in a disallowedconfiguration).

The use of passcodes (or other types of authentication information) forenterprise applications reduces the likelihood that enterprise resourceswill be improperly accessed when, for example, the mobile device is lostor stolen, or when the mobile device is used by an employee's childrento play games. In some embodiments, the secure launcher (or anothercomponent installed on the mobile device) further reduces this risk byperforming a selective wipe of the mobile device when, for example, theuser attempts but fails to enter a valid passcode a threshold number ofconsecutive times (e.g., 5 or 10). The selective wipe operation deletessome or all of the enterprise applications and associated data from themobile device, without deleting any personal applications or data. Insome embodiments, the enterprise's IT department can initiate aselective wipe of a particular mobile device by remotely issuing a wipecommand to the device.

In some embodiments, when a selective wipe operation is performed, someor all of the documents and data stored in the secure container aredeleted from the mobile device or are otherwise made inaccessible.

In another example, a meta-application can be configured to creategateway rules based at least partly on the time(s) at which a mobiledevice was “wiped” (e.g., deletion of some or all data stored on thedevice or removal of software application(s) from the device).

A system and process will now be described for enabling non-developers,such as members of a company's IT department, to add to or otherwisemodify the behaviors of an existing mobile application, such as anAndroid, iOS, or Windows Mobile application. The system and process canbe used, as one example, to create different versions of a mobileapplication (with different privileges, access rights, etc.) based on auser's role within the enterprise. For instance, different versions ofthe mobile application can be created for different job categories(e.g., executive, non-executive employee, intern, etc.) and/or differentdepartments (sales, IT, human resources, etc.). The processes describedin this section can be implemented in an application modification or“wrapping” tool or utility that is made available to enterprises thatuse the disclosed system. This utility may, for example, be hosted on aserver (e.g., as a web service) that is accessible to enterprises, ormay be provided to the enterprises (e.g., as a PC application).

In a typical use case scenario, the mobile application to be modified isa custom application developed for a particular enterprise. However,this need not be the case. For example, the disclosed system and processare also applicable to commercially available mobile applicationsavailable in app stores. The mobile applications can be modified withoutbeing specially written to support or enable such modifications. Forexample, the developer need not include any special code orfunctionality in the application to enable or facilitate themodifications, and need not be involved in the disclosed process ofmodifying the application.

The behaviors that are modified typically include or consist ofbehaviors that involve standard API calls or classes. The following areexamples of some of the types of behaviors that can be added or modifiedvia the disclosed process:

A mobile application can be modified to enable an enterprise to remotelyinitiate deletion of the application's data on a particular mobiledevice of a particular employee, without affecting other users of theapplication. As mentioned above, such selective wipe operations may alsobe executed when, for example, a user fails to enter a valid enterprisepasscode a threshold number of times.

Additional code may be added, if applicable, to implement one or morefeatures or behaviors that do not require the replacement of anyexisting API calls. As one example, code may be added for enabling anauthorized administrator to remotely trigger the deletion, on auser-specific or mobile device specific basis, of the application's datastored on a particular mobile device. In this example, the code addedwould add functionality for receiving and processing a messagecontaining a command to perform such a selective wipe or deletionoperation.

FIG. 54 shows an illustrative method for managing access by a mobiledevice to enterprise storage, as described above. Initially, a managedapplication may be received and/or installed in step 5401 on a mobileelectronic device, as described herein. In step 5403 the device mayseparately and/or distinctly receive one or more policy files definingone or more operational and/or behavioral limitations of the managedapp, e.g., based on one or more features discussed above. While thepolicy file(s) may be optionally received as separate files, the policyfiles may be received as part of a same communication or installationprocess as the managed app.

In step 5405 the mobile device executes the managed app in accordancewith the policy files. That is, the mobile device security manager (orequivalent process) restricts operations of the managed app as definedby the one or more policy files. In step 5407, during operation of themanaged app and based on one or more of the policy files, the managedapp may be restricted in accessing an enterprise data storage, thatmight otherwise have been allowed or disallowed had the policy file(s)not been enforced. Various examples of such policy files and featuresthat may be restricted/enforced are discussed above.

8.C. Single Sign-On and Identity Management

According to some aspects of policy-based device management, an EMMcontroller may incorporate single sign-on (SSO) features based onenterprise-level authentication. Single sign-on generally refers to aproperty of access control of multiple related, but independent softwaresystems. With SSO enabled a user logs in once and gains access to allsystems without being prompted to log in again for each separatesoftware system. Using authentication via network proxy, the EMM servicemay provide various forms of inline authentication challenges to provideseamless SSO, e.g., NTLM, Kerberos, digests, certificates, etc. Forexample, if an authentication challenge arrives via HTTP, a gateway mayintercept the challenge and automatically respond on a user's behalf.However, if a certificate is required, the certificate typicallyoriginates with a client to respond to an authentication challenge.

In view of the above, one or more policy files may define thecircumstances under which one or more applications operating under thecontrol of or in accordance with those policy files can and cannot usean SSO service to bypass an authentication or security challenge.

FIG. 25 depicts an illustrative system having a client device 2505, aproxy device 2510, resource(s) 2520, and/or authentication service(s)2515, which may be configured to perform SSO and operate under thecontrol of one or more policy files. FIG. 26 depicts an illustrativedetailed view of the client device 2505 and proxy device 2510. Theseelements may implement one or more aspects described herein. A briefsummary of these aspects will now be provided, with additional examplesprovided below. The client device 2505 may communicate with one or moreresources 2520 and/or authentication services 2515 using a proxy device2510. In some aspects, the client device 2505 might not be configured tocommunicate directly with the resources 2520 and/or authenticationservices 2515. For example, the client device 2505 and resources 2520may use different authentication and/or communication protocols. Theproxy device 2510 may translate between these different protocols.Additionally or alternatively, the proxy device 2510 may provideadditional benefits, as will be described in the examples below.

The client device 2505 may send a request for resources 2520, such asdocuments, emails, services, files, and the like, to the proxy device2510. The proxy device 2510 may forward the request to the resource2520, and in response, authentication between the proxy device 2510 andresource 2520 may be initiated. At one or more points during theauthentication, the resource 2520 may request a signature, such as froma client certificate. The proxy device 2510 might not directly haveaccess to the client certificate, so the proxy device 2510 may involvethe client device 2505 in the authentication process, such as if theclient device 2505 controls access to the client certificate. Forexample, the proxy device 2510 may request that the client device 2505sign or decrypt an authentication message using the client certificate(or a private key included therein), or return a list of availablesecurity certificates or a selection by the user of a particularsecurity certificate.

The proxy device 2510 may provide the client device 2505 with contextinformation that identifies the authentication session between the proxydevice 2510 and the resource/authentication server. For example, thecontext information may identify a data structure of authenticationinformation exchanged (or to be exchanged) between the proxy device 2510and resource 2520 and/or the proxy device 2510 and the authenticationservice 2515. The client device 2505 may use the context information toverify or otherwise confirm the authentication session between the proxydevice 2510 and the resource/authentication server. Once the contextinformation is verified, the client device 2505 may provide therequested signature to the proxy device 2510, and the proxy device 2510may complete authentication with the resource 2520 and/or theauthentication service 2515. Then, the proxy device 2510 may retrievethe resource requested by the client device 2505 and provide it to theclient device 2505.

The client device 2505 may comprise any of an end point device, clientcomputers 107, 109, 211-214, mobile device 302, mobile device 402, orany other device. For example, the mobile device may comprise any of asmartphone, a tablet, and the like. One or more applications may berunning on the client device 2505. An application may desire to access aprotected resource, such as an enterprise resource, and a moduleincluded in the application (or other applications) may facilitateaccess to those protected resources. For example and with reference toFIG. 26, an application running on the client device 2505 may send arequest for a resource (e.g., an HTTP request) to MAMP Framework 2605,which may facilitate communications with the proxy device 2510. In someaspects, the MAMP Framework 2605 may run as a privileged application onthe client device 2505. The MAMP Framework 2605 may comprise all of or aportion of the functionalities provided by the MAMP framework 414, aspreviously described.

The client device 2505 may also have a PKOperation SDK module 2610 thatfacilitates access to a keystore 2615 that stores one or more clientcertificates that may be used to sign for authentication purposes. Forexample, the client device 2505 may authorize access to or havepossession of client certificate(s) representing the user of the clientdevice 2505. In some aspects, the certificate may be anenterprise-issued certificate. The certificate may be bound to aphysical smart card having a cryptographic module. In other words, thecryptographic secret may be confined to the smart card. The user mayauthorize the client device 2505 to access the smart card protectedcertificate. Alternatively, the certificate may be bound to a virtualsmart card, which may use hardware and/or software modules to protectthe key. The client device 2505 and/or a removable hardware module ofthe client device 2505 may be authorized by a provisioning process tostore the certificate and private key. The user may be required to entera PIN code using the client device 2505 to authorize operationsinvolving the client certificate private key. Another external deviceseparate from the client device 2505 (e.g., another smartphone) maycontrol the certificate, and the client device 2505 may utilize a customreader interface to access the certificate controlled by the externaldevice.

In some embodiments, the client certificate and/or private key might beconfined to the client device 2505 or to a physical smart card.Accordingly, the client device 2505 may maintain control of the key. Ifauthentication using the key is required, the client device 2505 mayneed to be involved in the authentication process. This allows theclient device 2505 to have assurance that operations performed with thecertificate private key are ones that the client device 2505 intended.Some organizations may use smart cards to achieve non-repudiation forcertain operations, which may require users to have authority over alluses of a certificate issued by the organization. For example, documentsigning may require explicit user authority, whereas authentication tocertain systems might not require explicit user authority. Suitablemechanism(s) for providing such assurance may depend on the nature ofthe resource being accessed, the proxy device involved, and how theclient device 2505 operates.

The proxy device 2510 may comprise one or more of a server (e.g.,servers 201, 206, 1701, 410), computing device, access gateway 360,gateway server 406, or any other device. The proxy device 2510 mayfacilitate communications between the client device 2510 and enterpriseresources or other networks. For example, a user of the client device2505 may wish to access enterprise resources that requireauthentication, and the proxy device 2510 may mediate access. The clientdevice 2505 may use the proxy device 2510 to access resource if, forexample, the client device 2505 is not able to directly access theresources. For example, the client device 2505 might not be configuredfor a protocol utilized by the enterprise resources. In some aspects,the enterprise resource may implement Kerberos with PKINIT forauthentication, but the client device 2505 might not implement Kerberoswith PKINIT. Similarly, the enterprise resource may implement SSL withclient certificate authentication, but the client device 2505 might notimplement SSL with client certificate authentication. Instead, theclient device 2505 and proxy device 2510 may communicate using aprotocol having standard components and fitting well-knownauthentication frameworks. The proxy device 2510 may translate between afirst protocol to the resource (e.g., Kerberos or SSL) and a second,different protocol to the client device 2505 (e.g., HTTP or HTTPS). Byutilizing the proxy device 2510, client devices might not need tounderstand and operate a complex or different protocol used by theenterprise resource. In these examples, the proxy device 2510 may playthe client role. However, the proxy device 2510 might not have controlof the client certificate private key.

The proxy device 2510 may be used to facilitate access to resources inother circumstances, such as if the client device 2505 is not permittedto directly access the resources, if access capabilities of the clientdevice 2505 are limited, and/or if the proxy device 2510 enhances accessby improving performance or offering a preferable interface. The proxydevice 2510 may also facilitate enhanced security. For example, Kerberosresource authentication may require obtaining service tickets fromKerberos KDCs (e.g., Active Directory domain controllers). However, theKDCs themselves may comprise sensitive enterprise resources that shouldnot be directly accessible to some client devices. For these cases.Kerberos authentication may require use of a trusted proxy device 2510.As another example, the proxy device 2510 may be a hardenedcommunication gateway deployed in the DMZ network of an enterprise. Toprovide extra security benefits, the proxy device 2510 may be able toinspect communications being proxied to enterprise resources, ratherthan allowing a transparent end to end communication flow between theclient device 2505 and the enterprise resources as if the proxy device2510 were not present. That is, the proxy device 2510 may have knowledgeof what resources the client device 2505 is using and the protocols theclient device 2505 utilizes. As will be discussed in further detail inthe examples below, the proxy device 2510 may also provide, to theclient device 2505, context information that identifies one or moreaspects of the authentication session between the proxy device 2510 andan authentication service 2515 and/or resource 2520. The client device2505 may use this context information to determine whether or not tosign data provided by the proxy device 2510 that requires a signature.

The proxy device 2510 may include a packet engine 2620, which may be ahardware module and/or software module. The packet engine 2620 mayfacilitate communications with the client device 2505 and/or theresource. The proxy device 2510 may also include a session cache 2625.As will be described in further in the examples below, the session cache2625 may store a session key and/or ticket (e.g., for Kerberos sessions)to enable communications between the proxy device 2510 and one or moreresources or servers storing the resources. The proxy device 2510 mayinclude a client-side authentication module 2630 configured to manageauthentication with the client device 2505, such as obtaining asignature from the client device 2505. For Kerberos authentication, theclient-side authentication module 2630 may comprise a PKINIT module(which may be referred to as a likewise daemon) that implements theclient side of the public key form of the Kerberos authenticationprotocol (e.g., a PKINIT protocol). For example, this could be the kinitcommand line program that is available from open source implementationsof Kerberos.

The proxy device 2510 may also include a library module 2635 (e.g., aPKOperation Proxy SDK 2635) used by the client-side authenticationmodule 2635 to abstract details for accessing the client certificateprivate key.

The client device 2505 and the proxy device 2510 may communicate using astandard framework, such as an HTTP framework. In some aspects and aswill be described in the examples below, the client device 2505 andproxy device 2510 may exchange one or more authentication messages. Theymay exchange HTTP status codes, such as HTTP 401 codes for requestingauthentication, and/or challenge-response messages. In some embodiments,if the client device 2505 which receives a 401 authentication challengedoes not support secured exchange of client private certificates, theclient device 2505 may recognize the 401 message as an authenticationchallenge that the client device 2505 does not understand. The clientdevice 2505 may react with the appropriate error handling behavior, suchas displaying a message to the user that an operation could not becompleted because the client device 2505 does not support securedexchange of client private certificates. The HTTP level encoding tosupport public key operation remoting may be relatively simple. ThePacket Engine 2620 and the MAMP Framework 2605 may process the HTTPlevel encoding. Communications may be structure similar to the HTTPNegotiate authentication scheme described in RFC 4559, which isincorporated herein by reference in its entirety. Base64 encoded blobsmay be exchanged back and forth between the client device and proxydevice using WWW-Authenticate and/or Authorization headers. The blobsmay be generated and processed at each device by the respectivePKOperation SDKs (810, 2635).

In some embodiments, components in the communication path between theclient device 2505 and the proxy device 2510 that are HTTP aware mightnot interface with the authentication process. For example, an HTTPproxy server between the client device 2505 and the proxy device 2510may be aware that the connection to the proxy device 2510 should not bereused to send requests from other client devices and/or users.Furthermore, caching of any HTTP data returned from the proxy device2510 should be correctly scoped so that the data is not sent to anotherclient device.

In some aspects, authentication between the client device 2505 and proxydevice 2510 may utilize a standard authentication framework, such as webauthentication or Generic Security Services Application ProgramInterface (GSSAPI) with a custom mechanism. Objects may be transmittedfrom the proxy device 2510 to the client device 2505. The client device2505 may process the objects and validate them by standard cryptographicmechanisms, such as certificate path validation with a name check.

A specialized communication channel between the client device 2505 andproxy device 2510 may be created. For example, the specializedcommunication channel may be used to relay certificate operationrequests and results. Utilizing the specialized communication channelmay provide extra cryptographic protection beyond that provided by astandard SSL channel between the client device 2505 and the proxy device2510. This may be appropriate given the sensitivity of the inputs andoutputs of the cryptographic operations being remoted. In some examples,a Diffie-Hellman key exchange (or other exchange) between the clientdevice 2505 and the proxy device 2510 may occur. The exchange mayprovide mutual authentication between client device 2505 and proxydevice 2510. In some embodiments, mutual authentication may already havebeen established prior to a resource access request by the client device2505. Channel binding, as described in RFC5929, which is herebyincorporated by reference in its entirety, may be used tocryptographically link the specialized communication channel to an outerSSL session. With brief reference to FIG. 26, setting up the specializedcommunication channel for data, such as PK operation payloads, mayutilize multiple exchanges between the client device 2505 and the PacketEngine 2620. This may be opaque to everything except the PKOperation SDK2610 and PKOperation Proxy SDK 2635.

One reason for providing extra protection via the specializedcommunication channel is that SSL, in practice, may be terminated by anetworking device, such as an offload device, in front of the proxydevice 2510. Offload devices may be optimized for SSL connectionprocessing, such as by using specialized hardware for accelerating CPUintensive operations involved in SSL connections. The hardware modulemay also be certified to meet commercially important cryptographicprocessing standards, such as the Federal Information ProcessingStandard (e.g., FIPS-140). Another reason for providing extra protectionis that an inspection device may be given access to the SSL certificatekey in order to decode communications. The inspection device maycomprise a security device designed to monitor network traffic forcompliance with security policies, such as by detecting attempts to sendconfidential information outside of a trusted network zone, or attemptsto communicate with untrusted or unauthorized servers. Some of theseinspection devices may be configured to impersonate other servers duringSSL connection handshakes, in order to prevent the inspection processfrom being foiled by the use of encrypted communication channels. Usingthe specialized communication channel may prevent unnecessary and/orinappropriate exposure of sensitive data to the offload device and/orinspection device. Accordingly, non-repudiation properties expected fromusing smart card equivalent client certificates may be protected. Forexample, the specialized communication channel may prevent the data tobe signed from being modified by external devices and/or leaks ofdecrypted data.

The specialized communication channel may be implemented in many ways.For example and as previously noted, a custom GSSAPI mechanism operatinginside a standard HTTP authentication protocol may be utilized. Thisimplementation provides several non-exclusive benefits. First, the proxydevice 2510 may indicates to the client device 2505 in a standard way(e.g., HTTP) that authentication to a resource and/or authenticationserver is required to complete the requested resource access. Second, anarbitrary binary protocol may be conducted between the client device2505 and the proxy device 2510, with multiple rounds if necessary.Third, the implementation allows for secure communication mechanisms tobe negotiated and applied to transfer data in a standard way (e.g., atthe GSSAPI level). In some implementations, the custom GSSAPI mechanismoperating inside a standard HTTP authentication protocol can also allowfor a platform implementation of GSSAPI to be used with a custommechanism being added, such as the MICROSOFT NegoEx mechanism.

Referring to FIG. 25, one or more authentication service 2515 (or serverrunning the authentication service 2515) may exist. Authenticationservice 2515 may implement one or more types of authentication,including Kerberos or SSL. The aspects described herein may beimplemented for any authentication protocol that involves clientcertificate private key operations. For example, for Kerberos, theauthentication server may be tasked with issuing tickets, includingticket granting tickets and/or session tickets. The authenticationserver may communicate with the proxy device 2510 over one or morechannels. Furthermore, the one or more channels may use a communicationprotocol different from the communication protocol used by the clientdevice 2505 to communicate with the proxy device 2510. In some aspects,the authentication services 2515 might remain unchanged, even withimplementation of the aspects described herein. In other words, theauthentication services 2515 may exist in a traditional infrastructure.The authentication services 2515 may include, for example, theauthentication services 558 noted above.

One or more resources 2520 (or servers storing the resources 2520) mayexist. The resource 2520 may communicate with the proxy device 2510using one or more of the same or different protocols as theauthentication server uses to communicate with the proxy device 2510. Insome aspects, the resources might remain unchanged, even withimplementation of the aspects described herein. In other words, theresources may exist in a traditional infrastructure. Non-limitingexamples of resources may include, but are not limited to, fileresources, web resources, mail resources, Sharepoint resources, and thelike. These resources may include Structure Query Language (SQL)databases, remote procedure call (RPC) servers, Distributed ComponentObject Module (DCOM) servers, Simple Object Access Protocol (SOAP) webservices, Representational State Transfer (REST) web services, and otherproprietary resources that may use GSSAPI or a similar securityframework for authentication. One or more of these resources may bedirectly accessed by internal devices, such as computers on the samenetwork as the resources or in another protected network. The resourcesmay comprise the enterprise resources 304, 308, 408, 409 or the like.Furthermore, the resources may be stored on one or more servers. Theresources may be accessed through a multi-tier system. The proxy device2510 may communicate with a front-end server that may in turncommunicate (and authenticate as a requesting user) with a back-endserver.

The above described implementation is merely one possible systemarchitecture that may be used. Modifications may necessarily be madebased on an organization's particular implementation. For example, asystem as shown in FIG. 4 may alternatively be used, whereauthentication is part of the “logon” process. In such a system, amanaged app, when launched by a user, consults policy file(s), and maydetermine that a network logon is required for that app to fullyfunction. The managed app may request (e.g., through the client agent)to perform network login. If there is no logon session, the client agentmay initiate the logon sequest where the user is challenged forcredentials. The credentials may be passed securely to theauthenticating server and, if approved, the server issues the logontoken(s) which are then returned to the client agent. The client agentindicates logon success to the managed app, and therefore the managedapp is able to continue.

In another example, the managed app may perform SSO for a networkresource. The managed app may initiate network conversation with anenterprise network resource/server through a secure tunnel to thegateway which then forwards the network request to the enterpriseserver. Because the network resource requires authentication beforegranting access to the resource, the network resource may generate anauthentication challenge (SSL cert challenge or HTTP 401 auth requiredchallenge, etc.).

In some cases, an intermediate gateway may respond transparently to theauth challenge. The gateway monitors for authentication challenges inthe traffic that flows through the gateway. When an authenticationchallenge is recognized to which the gateway can respond, rather thanpassing the response back to the client, the gateway respondstransparently by retrying the request after adding the appropriateauthorization header or certificate derived from the gateway's notion ofwho the user is. For some HTTP auth protocols, this may include multiplechallenges and responses, all of which are handled transparently untilthe final authorization token is derived. In the end, the gatewaysupplies the appropriate certificate or HTTP auth challenge response andretries the operation. If successful, subsequent network traffic willcontinue to use the certificate or authorization response headerimplying the user never sees an authentication challenge.

In some cases, the gateway can generate the responses to the authchallenges independently (e.g. password replay). In other cases, it mayneed to interact with the client agent to derive the appropriatecredential and generate the response (e.g., Kerberos via PKINIT).

In other cases, the network challenge might not be visible becausetraffic being passed through the gateway has been encrypted, e.g., bySSL. Such challenges will pass back to the client app on the mobiledevice uninterrupted. Similarly, if the gateway encounters a challengethat it is not prepared to handle, the gateway allows the challenge toflow back to the client application on the mobile device.

In some cases, the managed app framework code may respond to an authchallenge transparently. If the gateway is unable see, intercept, andrespond to an auth challenge, then the challenge will flow back to theclient application on the mobile device. In this case, the managedapplication framework code includes its own authentication challengeawareness and that may allow the authentication challenge to respondtransparently without involving the application. The process is similarto the transparent gateway process above except that the auth challengeresponses originate in the managed application framework that sitsbetween the mobile OS provided network functions and the applicationspecific code that employs these services. When an SSL clientcertificate challenge is encountered, software in the managed appframework can recognize the callback and supply an appropriatecertificate. Similarly, if an HTTP status code 401 (AuthenticationRequired) is encountered, the managed app network framework code maygenerate the appropriate authentication response and retry the request.If successful, the authorization token or certificate are provided onall subsequent network requests and the end user never sees anauthentication challenge.

If the managed app framework encounters a challenge that the frameworkdoes not understand or is not prepared to handle, the framework allowsthe challenge to flow back to the client application and the app willbehave accordingly normally. In many cases, this will result in the userbeing challenged to authenticate him or herself (i.e., no SSO).

In some cases, the managed app may initiate a network conversation witha network resource/server that is reachable without the gateway actingas proxy (e.g., a general network resource not protected by the gateway,or where the mobile device is already directly on the internal corporatenetwork). In this case only the managed app framework might have anopportunity to see and respond to the authentication challenges from theserver, and the flow is similar as above.

For all of the above, application policy may serve to permit or limitsuch responses, or the location that intercepts a challenge, or thelocation from which a response is sent. Policies may also defineavailable certificates, etc.

When a second managed app subsequently requests authentication, thefirst authentication may be used to bypass a second logon. For example,when he second managed app is launched, the second manages app mayconsult policies and determine that network logon is required for thisapp. The second managed app signals the client agent to perform logon.However, because there is already a valid logon session being maintainedby the client agent (based on the first managed app), the client agentmay signal logon success to the second managed app, allowing the secondmanaged app to continue as an authorized app without interrupting theuser.

Similarly, regarding network resource single-sign-on (SSO) for secondmanaged app, the second managed app will have access to the same networklevel SSO facilities as the first managed app described above. However,the policies of the second managed app may be configured differentlyfrom the first managed app with respect to allowing or blocking variousforms of SSO. It may also have access to different certificates.

Thus, as indicated above, and using any or all of the above describedsystem architecture, one or more policy files may define thecircumstances under which one or more applications operating under thecontrol of or in accordance with those policy files can and cannot usean SSO service to bypass an authentication or security challenge.

FIG. 30 shows an illustrative method for managing single sign on accessby a mobile device, as described above. Initially, a managed applicationmay be received and/or installed in step 3001 on a mobile electronicdevice, as described herein. In step 3003 the device may separatelyand/or distinctly receive one or more policy files defining one or moreoperational and/or behavioral limitations of the managed app, e.g.,based on one or more features discussed above. While the policy file(s)may be optionally received as separate files, the policy files may bereceived as part of a same communication or installation process as themanaged app.

In step 3005 the mobile device executes the managed app in accordancewith the policy files. That is, the mobile device security manager (orequivalent process) restricts operations of the managed app as definedby the one or more policy files. In step 3007, during operation of themanaged app and based on one or more of the policy files, the managedapp may restrict or enable a single sign-on process, as discussed above.Alternative, the managed app may employ a single sign on credential inaccordance with the policy file(s). There are many examples of policyfiles and single sign on features and processes that may berestricted/enforced.

According to an aspect, one or more policy files may define what type,level, and/or location of SSO is allowed. For example, SSO may beallowed for users at a first level or role (e.g., management), but notat a second level (e.g., supervisors). As another example, SSO may beallowed by a first app (e.g., email), but not by a second app (e.g., aweb browser). As yet another example, SSO may be allowed based on basicor digest challenges, but not based on certificate challenges (or viceversa). Still further, complex combinations of requirements may bedefined in the policy files. For example, a managed web browser beingused by a user signed in as a manager might be allowed able to performany type of SSO, whereas the managed web browser might only be allowedto use SSO to respond to certificate challenges when in use by a usersigned in as a supervisor.

As another example, policy files may define permissible use of SSO basedon the resource being accessed, rather than the app doing the accessing.Resources may include documents, emails, files, services, and the like.Policy files may further define where SSO may be permitted to occur,e.g., on the device, at an intermediate gateway, etc. Still further,policy may define the types of permissible SSO challenges, e.g., basic,digest, OAuth, Kerberos, NTML, certificate, PKI, etc. According toanother aspect, a policy file may define an SSO policy based onpermissible authentication and/or communication protocol. Using any oneor more of the above policy-based features, an administrator can definea policy as simple or complex as needed by an organization.

9. DYNAMIC DEVICE CLOUD

Aspects described herein allow a collection of devices owned byindividuals or groups to be used in a coordinated, collective way,beyond simple screen sharing. This collective coordination of devicescan be done on either a memorized (for your own personal devices), or anad hoc basis (such as when two people use their devices collectively).

For example, consider online meeting software (e.g., the GOTOMEETINGsoftware application by Citrix Systems, Inc.). It exists on laptops,smart phones and tablets. However, each platform does essentially thesame thing and the devices do not work in harmony when used by the sameuser. According to one aspect, a smart phone may take on the role ofmicrophone for a meeting; a tablet may take on the role of displayingvideo for the meeting, and a laptop may display a screen sharing elementof the meeting.

Other examples of cross device coordination include: assigning web linksthat get clicked on by a laptop to appear on a tablet device, andtransferring an already opened PowerPoint presentation from one deviceto another.

In addition to the ability to assign specific roles to devices whileinteracting with devices, aspects allow for the persistent assignment ofdevice roles, to allow efficient usage of multiple devices, withoutextra interaction on the part of the user. For example, online meetingsoftware may involve making the smartphone the microphone, the tabletdisplay video, and the laptop display screen sharing immediately when ameeting starts.

In order to address the above problems, and other problems that willbecome apparent to the reader, aspects described herein harness andorchestrate devices together to allow complex multi device behaviorsthat make the internet of things come alive to make a big impact onpeople's daily lives. One problem solved by aspects described herein isto allow user level customization of behaviors that result when manydifferent devices interact with each other. One problem today is thatwhile many devices can interact with each other, the way they interactwith each other is hard wired, and not configurable by the users of thesystem. The range of behaviors is limited, and often limited to devicesfrom similar vendors, who have already established how devices willinteract with each other, based on specific, closed use cases.

Using aspects described herein, a user can configure flexibleinteractions between different devices to allow orchestration ofdifferent devices to work together in harmony. This allows devices whichare typically unrelated to work together to trigger different behaviors.For example, if a user has a smartphone, a laptop and a tablet, aspectsdescribed herein provide the following illustrative use-case solution:

a. If the user is driving in a car and a meeting starts, then they donot want to have to enter meeting join information—they just want themeeting to call them on the telephone using the PSTN, which allowssimple integration with the in car steering wheel phone controls.

b. However, if the user is in the office, then they want to use thedevice they are currently interacting with.

Aspects described herein give the user the choice to customize theseactions according to their preferences, utilizing triggers that areprovided by devices. Users can customize these actions either byexplicitly specifying them, or they can rely on the system observinguser behavior and following their preferences.

One known solution to the above recited problems is to manually carryout the orchestration steps between devices to achieve some of thefeatures the software described herein provides, such as manuallyconnecting to a meeting by dialing the PSTN bridge information while inthe car, despite the dangers of doing so.

Other features of the software described herein, such as triggers thatinvoke when a user is not physically present, cannot be achieved at themoment, and the user lives without such features. Limited known previousattempts at this problem involve solutions such as web mashups,including technologies like OnX and IFTTT. However, these technologiesare focused on bringing together different web sites and some featuresof mobile devices. They are not broader technologies that cover thewider range of devices that are part of “the internet of things”. Stillother known technologies include standards such as X10, DMX and ZWave.However, these are home automation technologies focused on devices andsensors such as light, motion sensors, and motorized control of items inthe home.

One known solution to the multi-device problem is to manually dedicatespecific devices to specific roles, through manual manipulation ofsoftware on devices. For example, in the context of online meetingsoftware, this can mean making the laptop screen minimize the video partof the meeting, to allow screen sharing to take up the screen, andmirroring this to the room display. It also means manually muting allspeakers other than that of the smartphone, which is acting as themicrophone. It also means making the tablet maximize the video displayof the online meeting software. Once after this is done, a single userappears to be connected multiple times in the list of users in ameeting, which provides a sub optimal user experience. For othersituations, such as launching an application from one device ontoanother, there are no existing solutions in place. Thus, existingsolutions, to the extent they exist, are laborious, manually driven anderror prone.

FIG. 27 shows multi-device use according to illustrative aspectsdescribed herein. The system of FIG. 27 outlines the way that items arespread across devices, as well as ways that users may trigger crossdevice interactions. As shown by way of example in FIG. 27, a user mayselect content at one computing device to share with another computingdevice. The user may select the content to share and then select one ofthe other computing devices connected via the orchestration framework.Upon selection of the selected computing device (the destinationcomputing device), the selected content may be transferred to theselected computing device. As seen in FIG. 27, various approaches may beselectively employed to present or display a set of computing devicesavailable for selection as the device to receive the selected content.In one approach, the computing devices available for selection may“peek” in from the edges of the interface as selectable targets of adrag-and-drop action. In another approach the computing devicesavailable for selection may be presented as a set of selectable icons.In a further approach, the computing devices available for selection maybe presented as selectable entries in a list of computing devices.Similar approaches may be employed in order to request that a computingdevice perform at least a portion of a computing activity initiated atanother computing device. Moreover, the set of computing devicespresented as available for selection may be dynamically generated orconfigured based on, e.g., the computing devices associated with thecomputing device, the computing devices associated with a user of thecomputing device, the computing devices co-located with the computingdevice, operation modes of the computing device, operation modes ofapplications at the computing devices, whether the computing devices arecapable of presenting the content or performing the computing activity,based on whether the computing devices are permitted to present thecontent or perform the computing activity, and additional or alternativecriteria that will be appreciated with the benefit of this disclosure.

FIG. 28 shows a system architecture according to one or moreillustrative aspects described herein. The system in FIG. 28 shows acloud service responsible for the server side facilities, andmulti-device (MD) software running on client devices responsible forcross device interaction. The MD software on each different kind ofclient device may be adapted based on the capabilities of that clientdevice. The system of FIG. 27 may include the following: 1) a cloudservice, which provides server and the back end services (this can beimplemented, e.g., using ASP.NET MVC running in Windows Azure); and 2)different client devices, each representing a different form factor ofdevice. A laptop, smartphone, tablet and large room display are shown inthe diagram, but other devices may also be used.

The cloud server components of the system may include:

-   -   a. Cloud file interface. This is responsible for communicating        with the underlying data cloud storage provider. In one example,        CITRIX SHAREFILE may be used. Other services may be used (e.g.,        DropBox, Box, etc.)    -   b. Cloud file service. Cloud-based file storage service, which        acts as an external data provider.    -   c. Device Service. This is responsible for maintaining knowledge        of all the devices that a user has, and the capabilities of each        device, such as what kind of device it is, what applications it        is capable of running, and what kind of peripherals (such as        cameras), that it has available.    -   d. Device Database. This database maintains the information used        by the Device Service.    -   e. User Service. This is responsible for maintaining knowledge        of all the users available in the system. It is also used for        identity management.    -   f. User Database. This is the database maintaining the        information in the User Service.    -   g. Device Management Interface. This is an interface that allows        users of the system to define what specific roles or actions        occur on what specific devices. It allows the user to customize        how their devices behave for specific situations, such as online        meeting software, or what device will display web content. It        defers the work of actually sequencing what goes to what device        to the Orchestration Service.    -   h. Push Notification Service. This is responsible for leveraging        push notification frameworks that are used by iOS, Android,        Windows, and other services to notify devices that they need to        take action.    -   i. Orchestration Service. This is responsible for coordinating        the different actions related to making devices display certain        content. It is a central point within the system and issues        instructions to all the other components

Client components of the system may be the same, regardless of the kindof device. However, implementation details may vary according to theunderlying platform. Client components may include:

-   -   a. Cloud file Interface. This is responsible for communicating        with the underlying data cloud storage provider.    -   b. Application Resolver. This is responsible for determining how        to act upon a request to engage in a cross device request. For        example, if the user wants to make use of a tablet as an online        meeting application video renderer, then the resolver determines        that the request involves launching the online meeting software        in video output mode only.    -   c. Notification Interface. Handles notifications that are        received from the server to engage in cross device behavior.    -   d. Application Launcher. Launches an appropriate application on        the device, after any data that needs to be brought to a device        is on the device.    -   e. Presence Subsystem. Ensures that the cloud service is aware        that a device is online and available. It may also transfer        location information or NFC related information, which may be        used by the server to determine if devices are co-located.    -   f. Orchestration Agent. This is responsible for orchestrating        work items related to a cross device activity so that a user can        accomplish their goals with minimal intervention. For example,        if a power point presentation is being transferred to this        device from another device, the orchestration agent ensures that        the presentation is available on the device, and downloads it to        the device if needed. The orchestration agent then makes use of        the application resolver to determine the appropriate way to        launch the application, and then using the application launcher        to launch the application.

As an illustrative example of how these components work together toaddress the above problems, the following describes the flow ofexecution during a use-case scenario where a user wants to launch amulti device online meeting application, and then display web links onanother device to that which the link was clicked upon.

Initially, prior to the meeting, the user has MD software client runningon his/her laptop. The presence subsystem of the client on the laptopcommunicates to the device service of the cloud service, to indicatethat the device is available. The presence subsystem of the client onthe user's smart phone and tablet indicate that the devices areavailable. At the time of the meeting, the Orchestration Service decidesthat it is time to start a meeting. The Orchestration Service consultswith the Device Service to determine what devices are available for theuser. The Device Service makes use of the Device Database to determinewhat devices a user has and what their status is. The OrchestrationService uses the Push Notification Service to send messages to theactive devices that the user has registered with the MD software. TheNotification Interface on the clients receive the notification that ameeting is to be launched and passes this onto the Orchestration Agent,which ensures that the user is asked if they want to join the meeting.The Orchestration Agent uses the Application Resolver to determine whatapplication and what parameters are needed to launch the meeting withthe given role. This information may be different for each device. Forexample, the laptop may be given information indicating that just screensharing is to be used, whereas the tablet may be given informationindicating that just the video is to be used. The Orchestration Agentuses the Application Launcher to start the online meeting software withthe appropriate information. This sequence may occur for each of theuser's active devices.

At the end of the meeting, the user then decides to make use of his/hertablet to display web content for links that are clicked on the laptop.The user clicks on a link in a web browser. The web link used isintercepted by the MD software. The MD software sends the link to theOrchestration Service at the cloud service. The Orchestration Serviceuses the Device Service to determine if the tablet is available. TheOrchestration Service sends a request to the Push Notification Serviceto send a push notification to the tablet device. The NotificationInterface on the client receives the request from the cloud service andpasses it onto the Orchestration Agent. The Orchestration Agent uses theApplication Resolver to determine which application and what parametersare needed to launch the particular web link. In this example, theinformation passed back is that the internal web browser needs to beused, and the information to pass to the browser. The OrchestrationAgent uses the Application Launcher to launch the web browser with theinformation passed from the other machine.

Using aspect described herein, the MD software overcomes thedifficulties involved in effectively using multiple devices together ina complementary fashion. Without the MD software, multiple devices arenot able to work together in harmony, in a complementary fashion. Eachdevice can display applications and content, but there is no coherenceor ability to orchestrate across multiple devices.

Using the MD software, for example, provides a user/enterprise theability to associate a person's devices with their identity in acollaboration system. Collaboration systems such as CITRIX GOTOMEETINGdo not currently have any particular association for a user's devices,and consequently cannot take advantage of pre-assigned roles fordifferent devices. The MD software also provides for associating deviceswith a space or group of people. Examples include conference roomdevices such as smart displays and speakerphones being associated with aspace. These assets can then be shared by a group occupying that space(temporary assignment) or be permanently assigned to a logical group ofpeople. The MD software also provides for the ability to move/assigninteractions across devices in the form of applications (native,virtual, web, etc.) with associated content and preferences in such away that it is seamless to spread work across devices. The MD softwarealso provides the ability to scaffold context/state across devices toafford better user experiences. For example, upon launch of acollaboration, the automatic launch of a meeting onto all a user'sdevices, with each device launching into its specific role. The MDsoftware also provides the context of one device (such as

Using the MD software, for example, provides a user/enterprise theability to associate a person's devices with their identity in acollaboration system. Collaboration systems also do not currently haveany particular association for a user's devices, and consequently cannottake advantage of pre-assigned roles for different devices. The MDsoftware also provides for associating devices with a space or group ofpeople. Examples include conference room devices such as smart displaysand speakerphones being associated with a space. These assets can thenbe shared by a group occupying that space (temporary assignment) or bepermanently assigned to a logical group of people. The MD software alsoprovides for the ability to move/assign interactions across devices inthe form of applications (native, virtual, web, etc.) with associatedcontent and preferences in such a way that it is seamless to spread workacross devices. The MD software also provides the ability to scaffoldcontext/state across devices to afford better user experiences. Forexample, upon launch of a collaboration, the automatic launch of ameeting onto all a user's devices, with each device launching into itsspecific role. The MD software also provides the context of one device(such as location of the phone) to be used as information for anotherdevice (such as a tablet). The MD Software also provides the ability touse device assignment/movement to afford device specific roles in acollaboration system. Examples include a smartphone acting as aspeakerphone, a tablet acting as an avatar, or any device acting as acamera. The MD software also provides targeted paste, e.g., allowing anapplication to be a paste target on one of the devices, subsequentcopies on any of the associated devices get pasted automatically intothe paste target. This cuts the typical copy and paste operationoverhead in half. The MD software provides methods and systems to make anatural user interaction (voice, touch, gesture, keyboard, etc.) actionon one device that allows all devices to respond. An example is to bringthe focus of an app (such as email) to the front on any of the devices.

Use the aspects described herein simplify the use of multiple devices byreducing manual configuration and coordination. Other aspects providethe ability to share world knowledge/state between devices to enhancethe user experience. This reduces redundant entry of information. Someaspects provide the ability to quickly spread activities across devicesby reducing the friction caused by applications, data, and context beinglocked into devices. Other aspects reduce copy/paste efforts in half.Some aspects provide cross device Natural User Interaction (NUI) thatallows less capable devices to participate in natural interaction. Otheraspects provide the ability to quickly bring an app to the front on anydevice, no matter what devices the app was on previously. This allowsfaster movement between applications, e.g., “show email on my tablet”.

According to another aspect, additional applications may benefit fromuse of MD software, e.g., client agent software in virtualizationenvironments. The MD software may enable migrating client agentapplications from one device to another device. This may be performedusing push driven Smooth Roaming. Other aspects of MD software mayprovide for the ability to share the state of web browser sessionsacross devices. Still other aspects of MD software may provide ad hocdevice discovery using technologies such as NFC and using theOrchestration Service and Orchestration Agent to assign roles for thedevices.

FIG. 29A illustrates a system architecture according to one or moreillustrative aspects. FIG. 29A outlines a general structure that may beused. It shows a cloud service responsible for server side facilitiesand new, dynamic software running on client devices.

The system architecture may include at least three discretesubsystems: 1) a cloud service, which provides the back end services(This may be implemented using ASP.NET MVC running in Windows Azure, asone example); 2) client devices, which run the software the userinteracts with for collaboration, deferred work, applications and othersoftware. This software can be running on platforms such as Windows,iOS, Android, Mac or a Smart TV, among others; and 3) internet enabledsensors, such as motion sensors, light sensors, temperature sensors.Client devices may be connected directly, each executing peer softwareas described herein, or may be connected through the cloud service(e.g., the cloud service may be optional, where the functionality isbuilt into software on each device).

Cloud service components of the system include:

-   -   a. Device Service, maintains knowledge of all the devices that a        user has, and the capabilities of each device, such as what kind        of device it is, what applications it is capable of running, and        what kind of peripherals (such as cameras), that it has        available.    -   b. Device Database. maintains the information used by the Device        Service.    -   c. User Service, maintains knowledge of all the users available        in the system. It is needed for identity management.    -   d. User Database. maintains all the information in the User        Service.    -   e. PSTN Interface, interface that proactively contacts users via        the public switched telephone network (PSTN).    -   f. Push Notification Service, leverages push notification        frameworks that are used by iOS, Android and Windows (among        others) to notify devices that they need to take action.    -   g. Orchestration Service, coordinates different actions based on        different events, or triggers that happen. The Orchestration        Service may include the following components:        -   2. Trigger Handler. receives input from different external            sources, such as sensors and clients about when specific            events occur that can act as a trigger for different actions            to occur.        -   2. Rules Service, determines what actions to carry out when            a particular event, or trigger, occurs. The Rules Service is            the core of the system that determines what to do when            something occurs.        -   3. Action Generator. translates the sequence of actions that            need to occur based on what the resultant actions generated            from the Rules Service are for a given trigger.    -   h. Rules Database. Maintains information used by the        Orchestration Service and Rules Service which determines how the        software behaves based on different triggers.    -   i. Orchestration Interface. Provides an interface for users of        the system to customize the behavior of the system for different        devices, events and triggers. It is through this interface that        the users customize the system.

The client components of the system may be the same, regardless of thekind of device. However, the implementation details may vary accordingto the underlying platform. Client components may include:

-   -   a. Application Resolver. This is responsible for determining how        to act upon a request that involves launching an application.        For example, if the user wants to launch Google maps on their        tablet when they enter a car, the Application Resolver        determines how to launch Google Maps—be it a web application,        native application, or client agent published application.    -   b. Notification Interface. Handles notifications that are        received from the server based on information from the server        side.    -   c. Application Launcher. Launches an appropriate application on        the device.    -   d. Presence Subsystem. Ensures that the cloud service is aware        that a device is online and available.    -   e. Orchestration Agent. Orchestrates the work items related to        making deferred and distributed work possible. This includes        tasks such as starting meetings in response to events from the        server, triggering authentication and general coordination of        the client. The Orchestration Agent may include the following        components:        -   1. Trigger Handler. Receives input from different external            sources, such as sensors and clients about when specific            events occur that can act as a trigger for different actions            to occur.        -   2. Rules Engine. Determines what actions to carry out when a            particular event, or trigger, occurs. The Rules Service is            the core of the system that determines what to do when            something occurs.        -   3. Action Generator. Translates the sequence of actions that            need to occur based on what the resultant actions generated            from the Rules Engine are for a given trigger.

To illustrate how these components work together to address the problemsthe software addresses, the following example use-case scenario showshow a user would set rules to ensure that if they are driving in a carwhen a meeting starts, that the system should call the user on the PSTNto let them join the meeting.

Initially, the user points their web browser to the OrchestrationInterface. The user enters a rule with the following definition:

-   -   a. A trigger set to “If a meeting starts”.    -   b. Contextual conditions set to “The motion sensor or GPS in my        smart phone indicates that I am moving at a speed greater than 5        km/h”.    -   c. An action set to “Call a specified telephone number and patch        me into the meeting automatically.”

The rule entered into the Orchestration Interface is sent to the RulesService, which writes the information to the Rules Database. At thispoint, the rules are all set up on the server. The Rules Serviceinstructs the Device Service to send each device a message with the newrules. The Presence Subsystem on the client device communicates with theDevice Service to indicate that the device is present. The clientreceives a response back indicating that it needs to update its rules.The Rules Engine on the client requests the latest set of rules thatapply to the device from the Rules Service. The Rules Service providesthe information back to the client, which stores the information in itsinternal Rules Engine configuration. Now that the client knows about therules specified by the user, it can send information about the state ofthis rule to the server. So, in this case:

-   -   a. The Trigger Generator on the client receives a message each        time the Presence Subsystem intends to notify the server about        its status.    -   b. The Rules Engine on the client determines that information        about the device's motion/speed needs to be sent back to the        server.    -   c. The Rules Engine uses the Action Handler on the client to        append information to the data sent back to the server by the        Presence Subsystem.

The Device Service on the server side receives the message about thedevice's presence, and the rule information from the client, which itpasses on to the Trigger Handler, which passes it onto the RulesService. The Rules Service updates its information about the state ofthe device, relative to the rule relating to meeting starting and motionsensor speed. When a meeting is due to start, the Trigger Handlerreceives a message from an external service monitoring the user'scalendar. The Trigger Handler passes the message about the start of themeeting to the Rules Service. The Rules Service consults the rulesdatabase and determines that there is a rule triggered by the start of ameeting. The Rules Service consults the rules database for furtherinformation about how the contextual condition for the rule relates tothe state of the client device. The status received last from the clientindicates that the device is moving and the contextual condition for therule evaluates to true, namely, carry out the action of the rule.

The Rules Service passes on the result of the rule evaluation to theAction Generator. In this case, it passes on an action of calling theuser on a specified telephone number. The Action Generator creates thesequence of instructions needed to call the telephone. The ActionGenerator issues a request to the PSTN Service to make a telephone callto the specified telephone number. The PSTN Service calls the requestedtelephone number, and connects to the user's telephone. The ActionGenerator issues a request to the PSTN Service to dial the appropriateinstructions to patch the user into the meeting they are due to attend.At this point, the user is connected into the meeting while they aredriving, without having to take their eyes off the road, or entercomplex sequences into their smart phone.

The software and systems described herein overcome the difficulties thatarise when users have several devices that can work together to automatetasks, yet are not configured out of the box to allow suchorchestration, or do not allow flexibility of orchestration. Aspectsdescribed herein thus provide the ability to define inferred contextual(temporal, geospatial, situational) and explicit (from all forms ofnatural interaction across devices) triggers from a variety of devices.Aspects also provide the ability to define actions for devices toperform based upon triggers determined from device context, and for thedefinition of rules that can be fired based on an inference engine toenable complex automation behaviors across devices. Aspects also providea question and answer interface to refine desired behaviors, as well asthe ability to learn how device behavior triggers based on learning orobserving user behavior across devices, instead of only relying on usersexplicitly scripting the behavior. For example, learning what a userdoes when they respond to something like a meeting notification, andreplicating this behavior the next time, such as automatically mutingtheir microphone, or setting it to a particular volume. Aspects alsoprovide the ability to learn device behavior based upon a question andanswer or if/then/else style interface.

While there are existing rules engines and automation frameworksavailable, they are typically related to one particular application ordevice. The dynamic device cloud described herein spans across multipledevices and applications that a user has. This provides severaladvantages, including providing the ability to provide future proofbehaviors of devices working together collectively, even if they are notexplicitly designed to cooperate with each other. Aspects describedherein also provide the ability to define simple triggers, actions, andbehavior rules to give a level of flexibility not available out of thebox in other solutions. Aspects also provide the ability to learn systembehaviors based upon question and answer style interfaces, and/or byobserving how a user uses the system can make customization accessibleto users without any programming background.

Other aspects described herein provide the ability for users tocustomize orchestration by providing a learning facility, a question andanswer style interface and a traditional scripting approach. Theorchestration software may adapt to how users interact with the system,and adjust rules based on user behavior. Thus, the system may learn newinteractions and rules, based upon the observed behavior of a user ofthe system.

As noted above, the cloud service may be utilized for sharing varioustypes of content at a computing device, e.g., for cross-device filesharing, URL sharing, and copy-and-paste functionality. The back-endcloud service advantageously allows cross-device sharing acrossdifferent operating environments using only a multi-device clientinstalled at the various devices. The content shared across devices maybe anything residing at a device including, e.g., document files, imagefiles, audio files, video files, archive files, software applications,URLs, text-based content, presentation meetings, and the like. Moreover,users may share content with devices they are associated with (e.g., apersonal mobile telephone, a personal laptop computer, a personal tabletcomputer, etc.) and may share content with devices associated with otherindividuals.

In some example implementations, a user may select the particular deviceselected content it is shared with. In other example implementations,the cloud service may automatically determine which device to share thecontent with. The cloud service may make the determination based on,e.g., the type of content shared, the devices presently connected to thecloud service, and so forth. This context-based decision-making of thecloud service advantageously provides a seamless and unobtrusiveworkflow for the users. Allowing users to select which devices contentis shared with, however, advantageously gives the users more controlover the destination of their shared content. It will thus beappreciated that the cloud service may be selectively configured toshare content between devices according to the selections of the users,according to the present context, according to file sharing rule sets,or a combination of such.

As noted above, the orchestration framework may also interconnectcomputing devices to operate as a coordinated whole via a peer-to-peercommunication session. FIG. 29B illustrates an example implementation inwhich the orchestration agents are interconnected via a peer-to-peercommunication session. The orchestration agents may still allow thecomputing devices to access, e.g., a cloud storage resource, a rulesdatabase, a device database, and a user database as described above. Itwill be appreciated that aspects of the orchestration framework areapplicable in the peer-to-peer context as well as the client-servercontext.

A word processing application (e.g., Microsoft Word) is one example ofan application where the orchestration framework may distributeoperation of the application across multiple interconnected devices. Inthis example, a desktop computing device may initiate the wordprocessing application and request that a television display devicepresent the output from the application, e.g., a document being edited.The orchestration framework may distribute the application across otherinterconnected computing devices such that input for the word processingapplication may be received from the other computing devicesinterconnected with the desktop application. For example, a user at alaptop device may provide input at the laptop keyboard in order to editthe document, and another user at a tablet device may provide input atthe touchscreen keyboard in order to edit the document. In this way, auser may share a document with other devices while accessing thedocument at a first device.

In another example, interconnected devices may coordinate with eachother if one of the devices does not have the hardware or softwareneeded to carry out a computing activity. Online meetings are providedin this disclosure as one example in which computing devices may beinterconnected via an orchestration framework that coordinates operationof a computing activity across the computing devices. In one particularexample, a user may only have access to a cellular telephone and atelevision display device when joining the meeting. In this example, thetelevision display device may not have an audio input device, and thecellular telephone may not have an adequate video output device.Accordingly, the orchestration framework may coordinate the operation ofthe cellular telephone and the television display device to enable theuser to join the online meeting. Respective orchestration agents at thecellular telephone device and the television display device may connectthe devices via the orchestration framework as shown by way of examplein FIG. 29B. During the online meeting, the orchestration framework maythus cause video of the online meeting to be presented at the televisiondisplay device and cause audio from the user to be received for theonline meeting from the microphone of the cellular telephone device.Additional and alternative examples will be appreciated.

FIG. 31 is a flowchart 3100 of example method steps for cross-devicefile sharing. A user may operate a computing device at which variouscomputer files reside. The user may select one of the files to sharewith another device (block 3102). With the file selected, the user mayinitiate a cross-device share request (block 3104). The user mayinitiate the cross-device share request via, e.g., a keyboard shortcut,menu selection, and the like. Upon initiation of the cross-device sharerequest, the multi-device client may launch or activate at the device(block 3106).

The multi-device client may present a list of destinations the user maytransmit the selected file to (block 3108). The list of destinations mayinclude line items corresponding to computing devices associated withthe user as well as line items corresponding to individuals. As notedabove, the user may select a personal device associated with that useror an individual to transmit the selected file to. As also noted above,the list of line items may include the devices associated with thelisted individuals, and the user may select which device associated withan individual to transmit the selected file to. If the user selects anindividual rather than a device, the cloud service may automaticallydetermine which device associated with the selected individual totransmit the selected file to. It will be appreciated that the list ofindividuals may also include the user, and selection of the user maytransmit the selected file to a different device associated with theuser.

As noted above, the determination of which device to transmit theselected file to may be based on user selection, context, or rule sets.The user may manually select which device or individual to transmit theselected file to. Additionally or alternatively, the cloud service maydetermine which devices are presently connected to the cloud service,and automatically select one of those devices to receive the selectedfile. The cloud service may also automatically select a device based onthe type of file selected. As an example, the cloud service may selectan audio device to receive the selected file when the file is an audiofile. As another example, the cloud service may automatically select alarge display device to receive the selected file when the file is avideo file. The cloud service may also employ one or more rule sets todetermine which device should receive the selected file. Users maymodify the rule sets according to their preferences, and the rules mayconsider various characteristics associated with the users (e.g., userrole, location, etc.), the devices (e.g., device type, etc.), theselected file, and combinations of such. This rule-based approach tofile sharing may advantageously provide greater flexibility incustomizing how the cloud service automatically shares files acrossdevices.

Moreover, the list of destinations may be context-sensitive such thatthe destinations included in the list depend on various factors. In oneexample implementation, the multi-device client may dynamically filterthe list of destinations based on the capabilities of the potentialdevice destinations. In this regard, the multi-device client may beaware of the capabilities of the various devices. The cloud service maymaintain capability information corresponding to each device connectedto the cloud service and provide this capability information to themulti-device client. In turn, the multi-device client may utilize thecapability information when constructing the list of destinations. If apotential device destination is not capable of opening the selectedfile, then the multi-device client may exclude that device destinationfrom the list of destinations. In this way, the multi-device client maytailor the list of destinations to include only those devices having thecapability to open the selected file. The multi-device client may tailorthe list of destinations based on additional or alternative criteria.For example, the individuals included in the list of destinations may bethe attendees of an ongoing meeting that the user is attending. It willbe appreciated that the multi-device client may employ combinations ofcriteria to construct the list of destinations.

Referring back to FIG. 31, the user may select from the list ofdestinations a destination to transmit the selected file to (block3110). Having selected the destination, the multi-device client mayupload the selected file to a remote file sharing service that storesthe selected file (block 3112). The multi-device client may then notifythe cloud service that the selected file is available at the filesharing service (block 3114). The notification to the cloud service mayinclude, for example, the selected destination for the file, thelocation of the file at the file sharing service (e.g., a URLcorresponding to the file), and the like. The cloud service may thennotify the destination device that the file is available at the filesharing service (block 3116). The notification to the destination devicemay likewise include the location of the file at the file sharingservice.

The multi-device client at the destination device may responddifferently depending on whether the user shared the file with a deviceassociated with that user (e.g., another personal device) or a deviceassociated with another individual. In particular, the multi-deviceclient may present an unobtrusive notification at the mobile device whenanother user shares a file. In this way, the multi-device client mayavoid interrupting users while engaging in other computing activities.As seen in FIG. 31, if the destination device is not a personal deviceof the user that shared the file (block 3118:N), then the multi-deviceclient at the destination device may display a notification that a newfiled has been shared with the destination device (block 3120). Uponreceipt of the notification of the shared file, the multi-device clientmay provide the recipient with the option to accept or reject the sharedfile. If the recipient does not accept the shared file (block 3122:N),then the multi-device client may wait (block 3124) until the recipientaccepts the shared file, e.g., by providing input requesting receipt ofthe shared file. When the recipient accepts the shared file (block3122:Y), the multi-device client may retrieve the file from the filesharing service (block 3126). The file sharing service may be locatedremotely relative to the device the multi-device client resides at, andmay be accessible, e.g., via the Internet. Accordingly, the multi-deviceclient may submit a request to the file sharing service using the URLcorresponding to the location of the shared file at the file sharingservice. The multi-device client may download the file from the filesharing service and launch the appropriate application at thedestination device to open the file (block 3128).

In some example implementations, the multi-device client may beconfigured to automatically respond to a file share. Accordingly, if thedestination device is a personal device of the user that shared the file(block 3118:Y), then the multi-device client may automatically retrievethe shared file from the file sharing service (block 3130) uponnotification of the shared file. When the multi-device client receivesthe shared file from the file sharing service, the multi-device clientmay also automatically launch the appropriate application at thedestination device to open the shared file.

It will be appreciated that the example approach described aboveprovides a quick and efficient way to share, e.g., email attachments.Instead of forwarding or creating new emails to share email attachments,users may share email attachments using the cloud service whichstreamlines the sharing process. The example approach described abovealso provides a quick and efficient way to share online presentations ormeetings with other devices or individuals. Instead of having userslaunch and log on to join an existing meeting, a user may share themeeting information and details with another individual using the cloudservice, and that meeting may automatically launch at a device utilizedby the individual. Similarly, the cloud service allows an attendee totransfer an ongoing meeting presented at one device to another deviceassociated with the attendee. As an example, an individual may attendedan online meeting using a desktop computing device. If the individualneeds to leave the desktop device for any reason, the individual may usethe cloud service to transfer the meeting to a mobile device such as atablet computing device or mobile phone device. In this way, users arenot tied to any particular device when attending an online meeting andmay advantageously jump between devices while attending the meeting.

FIG. 32 is a flowchart 3200 of example method steps for cross-device URLsharing. Similar to selecting a file to share, a user may select a URLto share (block 3202), e.g., by highlighting the URL. The user may theninitiate a cross-device request as described above (block 3204) andlaunch the multi-device client (block 3206). The user may select adestination from a list of destinations (block 3208), e.g., anotherdevice or an individual. With the destination selected, the multi-deviceclient may upload the URL to the cloud service (block 3210). The cloudservice may similarly notify the destination device of the shared URL(block 3212). The notification may include the shared URL.

As with sharing files, the multi-device client at the destination devicemay respond differently depending on whether the destination device isassociated with the user that shared the URL or another individual. Asnoted above, if the destination device is not a personal device of theuser that shared the URL (block 3214:N), then the multi-device clientmay display a notification indicating the shared URL (block 3216) so asto avoid any interruptions of other computing activities occurring atthe destination device. If the individual does not accept the shared URL(block 3218:N), then the multi-device client may wait (block 3220) untilinput is received indicating acceptance of the shared URL. When therecipient accepts the shared URL (block 3218:Y), the multi-device clientmay initiate launching of a web browser at the destination device aswell as a request for the shared URL (block 3222). If the user sharesthe URL another personal device (block 3214:Y), then the multi-deviceclient at the destination device may automatically initiate launching ofa web browser and request the shared URL (block 3224).

The cloud service may be configured to share URLs in a context-sensitivemanner. In particular, the cloud service may recognize URLs fordifferent types of online resources, e.g., a text-based webpage and avideo sharing webpage. Accordingly, the cloud service may automaticallyselect a destination device based on the URL type. As an example, thecloud service may recognize that the URL addresses a video sharingwebsite and, in response, select a large display device to share the URLwith. In this way, the cloud service may advantageously share the URLwith the device suitable for presenting the content addressed by theURL. As another example, the cloud service may recognize that the URLaddresses a text-based website and, in response, select a tablet deviceor desktop device to share the URL with. The cloud service may alsoemploy rule sets to determine which device to share the URL with. Forexample, a URL sharing rule set may list various websites and thedevices or types of devices the cloud service should select when sharingURLs associated with those websites. Users may configure the rule setsaccording to their preferences in order to customize the behavior of thecloud sharing service when sharing URLs. The rule sets may be associatedwith individual users for use when those users share the URL, andadditionally or alternatively, the cloud service may maintain a globalrule set applicable to all users.

FIG. 33 is a flowchart 3300 of example method steps for cross-devicecopy-and-paste functionality. Stated generally, a user may selectcontent at one device and copy the content to a clipboard at the cloudservice from which other users may paste the content at their owndevices. A user may first select the content to share (block 3302),e.g., by highlighting text or otherwise selecting the content. The usermay then initiate a cross-device request as described above (block3304), and the multi-device client may launch or otherwise activate(block 3306). The multi-device client may then upload the content to aglobal clipboard of the cloud service (block 3308). The global clipboardcorresponds to a storage location at the cloud service accessible to atleast some of the devices connected to the cloud service.

When a user copies content to the global clipboard, the cloud servicenotifies one or more of the devices connected to the cloud service thatnew clipboard content is available (block 3310). Users may utilize themulti-device client to paste the global clipboard content at theirrespective devices. The multi-device client may transmit a request tothe cloud service for the global clipboard content. When the cloudservice receives the request (block 3312), the cloud service maydownload the global clipboard content to the device (block 3314). Havingreceived the global clipboard content from the cloud service, the usermay paste the content into an application at the device (block 3316).

As set forth above, a device may not have the capability to open a fileshared with that device. For example, the application used to open theshared file may not be installed at the destination device.Nevertheless, the cloud service and multi-device client may beconfigured handle situations where a destination device does not havethe capability to open a shared file. As described in more detail below,the cloud service may automatically launch a virtual environment thathas the capability to open the shared file, and the multi-device clientmay launch a virtualization client to connect to the virtual environmentwhen a destination device is not capable of opening a shared file.

FIG. 34 is a flowchart 3400 of example method steps for launching ashared file at a destination device. The cloud service may receivenotification of a shared file (block 3402) as discussed above. The cloudservice may then determine whether the destination device is capable ofopening the shared file (block 3404). As noted above, the cloud servicemay store device capability information and may thus be aware of thecapabilities of the devices connected to the cloud service. Devices mayprovide the cloud service with their respective capability informationduring the negotiation process when connecting to the cloud service. Ifthe destination device is capable of opening the shared file (block3406:Y), then the device may launch the appropriate application to openthe shared file, e.g., automatically or in response to receipt of inputaccepting the shared file as discussed above.

If the destination device is not capable of opening the shared file(block 3406:N), then the cloud service may initiate creation of avirtual environment (block 3410). The cloud service itself may createand maintain the virtual environment locally or, additionally oralternatively, a virtualization server that is located remotely relativeto the cloud service may create and maintain the virtual environment.The virtual environment may be configured with the capability to openthe shared file (block 3412). As an example, the virtual environment maybe configured to include the application used to open the shared file.The virtual environment may also be provided with the shared file (block3414). As an example, the cloud service may provide the virtualenvironment with the location of the shared file at the file sharingservice, and a multi-device client at the virtual environment mayretrieve the file from the file sharing service. In this regard, thevirtual environment may also be considered as a destination for theshared file.

Once the virtual environment retrieves the shared file from the filesharing service, the virtual environment may launch a virtualizedapplication to open the shared file (block 3416). The multi-deviceclient at the destination device may launch a virtualization client(block 3418), and the virtualization client may connect to the virtualenvironment (block 3420). In this way, users may advantageously sharefiles across devices that may not be equipped to open those files. Amore particular example may include a 3D formatted computer file thatcan only be opened using 3D modeling software. A mobile phone may not beequipped with the necessary software to open the 3D file. Using thecloud service and the virtualization approach described above, a virtualenvironment may launch a virtualized instance of the 3D modelingsoftware, and the virtualization client at the mobile phone may connectto the virtual environment to access 3D files shared with the mobilephone device. Other practical uses will be appreciated with the benefitof this disclosure.

FIG. 56 shows an illustrative method for managing process transfers anddevice integration using a mobile device and based on one or more policyfiles, as described above. Initially, a managed application may bereceived and/or installed in step 5601 on a mobile electronic device, asdescribed herein. In step 5603 the device may separately and/ordistinctly receive one or more policy files defining one or moreoperational and/or behavioral limitations of the managed app, e.g.,based on one or more features discussed above. While the policy file(s)may be optionally received as separate files, the policy files may bereceived as part of a same communication or installation process as themanaged app.

In step 5605 the mobile device executes the managed app in accordancewith the policy files. That is, the mobile device security manager (orequivalent process) restricts operations of the managed app as definedby the one or more policy files. In step 5607, during operation of themanaged app and based on one or more of the policy files, the managedapp may restrict or enable the ability of a device to transfer a processor integrate with one or more other devices and/or resources, asdiscussed above. Various examples of such policy files and deviceintegration features and processes that may be restricted/enforced arediscussed above.

10. MULTIPLE OPERATION MODES

An improved technique for managing enterprise applications on mobiledevices allows users to access enterprise applications from their ownmobile devices, where the enterprise applications securely coexist withthe users' own personal applications and data. Enterprise mobileapplications are specially created or adapted in such a way that theyare forced to interact with other applications and services on a mobiledevice through respective application policies. Each enterprise mobileapplication running on the mobile device has an associated policythrough which it interacts with its environment. The policy selectivelyblocks or allows activities involving the enterprise application inaccordance with rules established by the enterprise. Together, theenterprise applications running on the mobile device form a set ofmanaged applications. The policy associated with each of the managedapplications includes a record of each of the other managedapplications. Typically, policy settings for interacting with managedapplications are different from policy settings for interacting withother applications, i.e., applications which are not part of the managedset, such as a user's personal mobile applications. Managed applicationsare typically allowed to exchange data with other managed applications,but are blocked from exchanging data with other applications, such asthe user's own personal applications. In some examples, applicationpolicies of managed applications are configured to allow links and/oricons presented in one managed application to be followed or opened inanother application only if the other application is also a managedapplication.

For example, a managed email application can be configured, through itspolicy, to allow an attachment to be opened in a managed PDF annotator.But the same managed email application can be configured to prevent thesame attachment from being opened in a PDF annotator that is not part ofthe managed set.

By constraining managed applications to interact on a mobile devicethrough enterprise-administered policies, the managed set ofapplications can thus be made to operate with other applications in themanaged set of applications, but can be prevented from operating withapplications that are not part of the managed set. Leakage of enterpriseinformation out of the managed set of applications can thus beprevented, as can be receipt of personal information into the managedset of applications. Certain embodiments are directed to a method ofmanaging applications of an enterprise on a mobile device. The methodincludes installing a set of managed applications of the enterprise onthe mobile device, wherein other applications are installed on themobile device that are not part of the set of managed applications. Themethod further includes receiving a set of application policies, whereineach of the set of managed applications is associated with a respectivepolicy of the set of application policies. The method still furtherincludes selectively allowing a first application of the set of managedapplications to provide data to a second application installed on themobile device, responsive to accessing a policy of the first applicationand reading an indication from the policy of the first application thatthe second application is a member of the set of managed applications,and selectively blocking the first application from providing data to athird application installed on the mobile device, responsive toaccessing the policy of the first application and failing to read anindication from the policy of the first application that the thirdapplication is a member of the set of managed applications.

An improved technique for managing enterprise applications on mobiledevices allows users to access enterprise applications from their ownmobile devices, where the enterprise applications securely coexist withthe users' own personal applications and data.

Secure data sharing is accomplished by creating a managed set ofapplications that can share files and/or data with one another, but areselectively prohibited from sharing files and/or data with applicationsthat are not part of the managed set. Thus, two objectives are achieved:(1) data are prevented from leaking out of the managed set and (2) dataare allowed to be shared among the applications within the managed set.FIG. 35 shows an example environment in which embodiments hereof can bepracticed. Here, a mobile device 3510, such as a smartphone, tablet,PDA, and the like, has installed upon it various mobile applications.The mobile applications include a set 3520 of managed applications 3522,3524, and 3526, and a personal application 3530. In some examples, anenterprise mobility management (EMM) client 3540 is also installed onthe mobile device 3510. The EMM client 3540 is configured to connect,e.g., via a network such as the Internet, with an EMM server 3550, whichtypically includes an authentication server 3552 and an applicationstore 3554. An example of the EMM client 3540 is a client agentavailable from Citrix. An example of the EMM server 3550 is a gatewayserver that provides access to enterprise resources and/or cloudresources. Each application in the set 3520 of managed applications isassociated with a respective policy. For example, application 3522 isassociated with a policy 3522 a, application 3524 is associated with apolicy 3524 a, and application 3526 is associated with a policy 3526 a.In some examples, the policies 3522 a, 3524 a, and 3526 a are providedin the form of files, such as XML or JSON files, in which the respectivepolicy is expressed as a set of key/value pairs. In an example, eachpolicy 3522 a, 3524 a, and 3526 a includes a record of all applicationswithin the set 3520 of managed applications, e.g., as discussed above.Each of the set 3520 of managed applications is specially designed oradapted for use with the enterprise. Some of the set 3520 of managedapplications may be designed specifically for the enterprise. Others ofthe set 3520 of managed applications are more widely used applications(e.g., available to the public) that have been specifically adapted foruse with the enterprise. Each of the set 3520 of applications includesinjected code that enables the application to conform to a framework ofthe enterprise. The injected code can be compiled into the applicationusing an SDK. Alternatively, the injected code can be applied as awrapper around a general-use application, to adapt it for use with theenterprise. In general, the injected code serves to divert API callsfrom the application to its associated policy, such that the policy canselectively allow or block activities specified by the API calls.

In typical operation, a user of the mobile device 3510 starts the EMMclient 3540, logs on to the EMM server 3550 via the authenticationserver 3552, and accesses the application store 3554. The user can thenperuse enterprise applications available from the application store3554, select desired applications, and download them to the mobiledevice 3510, where the downloaded applications are included in the set3520 of managed applications. For each application downloaded, acorresponding policy is also downloaded to the mobile device, and thepolicies of all applications in the set 3520 are updated to reflect allmembers of the set 3520. In an example, policies (e.g., 3522 a, 3524 a,and 3526 a) are refreshed periodically and/or in response to particularevents, such as each time the respective application is started and/oreach time the user logs onto the EMM server 3550. Policies can thus beadapted over time and dynamically transferred to the mobile device 3510from the EMM server 3550.

Depending on settings of the policies 3522, 3524, and 3526, applicationswithin the set 3520 of managed applications can be constrained toexchange files and/or data only with other applications within the set3520. For example, API calls from the application 3522 are interceptedby the injected code of the application 3522. The policy 3522 a is read,and the operation specified by the API call is either blocked or alloweddepending on the settings in the policy 3522 a. Because the policy 3522a has a record of all applications in the set 3520 of managedapplications, the application 3522, by reading the policy 3522 a, cantest whether the requested operation of the API call involves anapplication inside or outside the set 3520, and allow or block activityaccordingly. Thus, based on policy settings, movement of data can berestricted such that data within the set 3520 of managed applications isnot comingled with data outside the managed set (e.g., with application3530).

In some examples, applications in the set 3520 of managed applicationson the mobile device 3510 can be assigned to different groups. In suchcases, policies (e.g., 3522 a, 3524 a, and 3526 a) are updated toinclude records of groups and group members. The flow of files and/ordata between applications can thus be further restricted to members ofparticular groups. Providing different groups of mobile applicationswithin the managed set 3520 can help to segregate applications handlinghighly sensitive data from those that handle less sensitive data.

It is understood that the above-described process of intercepting an APIcall, consulting an application's policy, and allowing or blocking theoperation specified by the API call based on the policy can be carriedout in a number of contexts. In one example, the above process can beapplied for selecting a set of applications on the mobile device 3510that can be used to open a file or data element identified by a link oricon (e.g., using Open In). In another example, the above process can beapplied for copying data or data objects from one application andpasting the data or data objects in another application (e.g., via ahidden, encrypted paste buffer). In yet another example, the aboveprocess can be applied for moving files into and/or out of a protectedfile vault. Essentially, any operation used to move data into and/or outof an application can make use of the above technique.

It is further understood that this techniques can apply not only tomovement of data to other applications, but also to recording, pictures,printing, playback of audio, and other functions.

Operating system extensions may be obtained for the mobile device 3510.One such operating system extension responds to a user pointing to alink or icon representing a data object, such as a file, by displaying alist of applications on the mobile device 3510 that are capable ofopening that data object. An example of such an operating systemextension is “Open In,” which is available on iOS devices. Similarextensions are available for Android and Windows 8 devices.

In an example, applications within the set 3520 of managed applicationssupport the use of Open In, but the list of applications displayed foropening a selected data object is limited based on the policies of therespective applications. For example, the list of applications displayedwhen Open In is invoked from the application 3522 can be limited, inaccordance with the policy 3522 a, only to other applications in themanaged set 3520. Thus, in this example, Open In lists only applicationsthat are both (1) within the managed set 3520 and (2) compatible withthe data object. On mobile operating systems, such as iOS, Android, andWindows 8, each application runs in its own sandbox. These apps use avery high level content sharing mechanism like Open In in iOS,Intents/activities in Android and Charms in Windows8. On a BYOD (bringyour own device) mobile device, it will have a mix of managed andun-managed/personal applications running on the device. Here, we focuson how to enable data sharing among the managed set of applications.

On modern mobile operating systems like iOS, the file system is notreally exposed to the end user by design to hide complexity. The focusis rather on the applications and the data they handle.

There are many ways data can move in and out of the device. Primaryexamples include email, cloud based data/file sharing services, browseretc. Then the data needs to be moved among the managed applications toget actual work done.

A method and system for operating an application with multiple modes aredescribed. A plurality of applications may be presented to a user on amobile device and one of the displayed applications may be selected. Theselected application may have one or more contexts that are determined.For example, a context for the selected application may be that theapplication is configured to access an enterprise account. Based on thecontext, the selected application may be run on the mobile device in oneof a plurality of operations modes. The operation modes may compriseunmanaged and one or more managed modes, among others. Multiple managedmodes may be used to provide different levels of security, access todifferent resources, and the like.

In an embodiment, the context for the selected application may comprisean account to be accessed by the selected application, a location forthe mobile device that will be running the selected application, adetermination as to whether a predetermined application is running onthe mobile device, one or more network connections for the mobiledevice, and one or more settings for the mobile device. One or more ofthese contexts may be compared to policies to determine an operationmode for the selected application.

In another embodiment, an operation mode may be switched for a selectedapplication. One or more contexts may be monitored for the selectedapplication while running and a change in operation mode may be detectedbased on the monitoring. For example, one or more contexts may changefor the selected application and a policy may define that an operationmode for the selected application is to be changed. Accordingly, theoperation mode may be switched to the updated operation mode.

In an embodiment, an application that is capable of running in multiplemodes, e.g., managed mode and/or unmanaged mode among others, may becontrolled by partition, by policy, by one or more sandboxes, or anyother suitable configuration. For example, a managed operation mode mayinclude running the application as a part of a managed partition of amobile device. In an embodiment, an application running in managed modemay access data stored in a secure data container in the managedpartition of the mobile device. The data stored in the secure datacontainer may include data restricted to a specific secure application,shared among other secure applications, and the like. Data restricted toa secure application may include secure general data and highly securedata. Secure general data may use a strong form of encryption such asAES 128-bit encryption or the like, while highly secure data may use avery strong form of encryption such as AES 256-bit encryption. In anembodiment, an application running in managed mode may save, modify, ordelete data in secure data container. The data saved or modified may beencrypted similar to other data stored in secure data container. In thisexample, an unmanaged operation mode may include running the applicationas part of unmanaged partition, as described above.

In an embodiment, an application running in managed mode or unmanagedmode may be controlled by policies. As such, one or more policies maydefine that the application running in managed mode may access secureddata (e.g., data in secure data container, encrypted data, such as dataencrypted with a particular key, or any other suitable secured data),may communicate with a secure server (e.g., gateway server), may bemanaged by a device manager (e.g., device manager), or any othersuitable policy. One or more policies may also define that theapplication running in unmanaged mode may not access secure data (e.g.,data in secure data container, encrypted data, such as data encryptedwith a particular key, or any other suitable secured data), may notcommunicate with a secure server (e.g., gateway server), may accessunsecured data (e.g., unsecured data container, unencrypted data, or anyother unsecured data), or any other suitable policy. In this example, anapplication running in managed mode and an application running inunmanaged mode may either include partitions (e.g., managed partitionand unmanaged partition) or may not include partitions.

In an embodiment, an application running in managed mode or unmanagedmode may be controlled by one or more sandboxes. A sandbox may comprisea physical or virtualized portion of a device where applications runningin the sandbox may include access policies that are different fromaccess policies for applications that are not running in the sandbox.For example, an application running in managed mode may run in a sandboxthat includes policies for the managed mode, such as the policiesdescribed herein. In another example, an application running inunmanaged mode may run in a sandbox that includes policies for theunmanaged mode, such as the policies described herein. In this example,an application running in managed mode and an application running inunmanaged mode may either include partitions (e.g., managed partitionand unmanaged partition) or may not include partitions.

FIG. 36 illustrates a sample interface of a mobile device, and FIGS.37-43 illustrate sample embodiments of methods for determining anoperation mode for an application. The methods depicted in FIGS. 37-43may be combined in any suitable manner in various embodiments. Thesample interface depictured in FIG. 36 may be displayed on a mobiledevice, such as device 107, 109, 240, 502, and/or 602, and the methodsdepicted in FIGS. 37-43 may be implemented by such a mobile device.

In FIG. 37, a flowchart of example method steps for determining anapplication mode for an application is shown. The method of FIG. 37 maybegin at step 3702, where a plurality of applications are presented. Forexample, a plurality of applications may be presented to a user on amobile device. FIG. 35 illustrates an embodiment where user interface700 displayed on a mobile device (e.g., tablet, smart phone, or thelike) presents Applications A 700, B 701, C 702, and E 703 to a user.This is merely an example, and the plurality of applications may bepresented in any suitable manner. In an embodiment, the plurality ofapplications may comprise email applications, web browsing applications,software-as-a-service (SaaS) access applications, and the like.

The method of FIG. 37 may proceed from step 3702 to step 3704, where aselection for one of the plurality of applications is received. Withreference to an embodiment depicted in FIG. 35, a user of a mobiledevice may select one of the presented applications by, for example,pressing a display of the mobile device to select the application. Thisis merely an example, and the application may be selected in anysuitable manner.

The method of FIG. 37 may proceed from step 3704 to step 3706, where acontext for the selected applications is determined based on one or moreoperational parameters of the device executing the selected application.For example, a context may be based on an account to be accessed by theapplication, a location of the mobile device or a network connectivitystatus of the mobile device executing the application, or based on anyother operational parameter. The methods of FIGS. 38-42, furtherdescribed below, illustrate various embodiments where example contextsare described.

The method of FIG. 37 may proceed from step 3704 to step 3706, where anoperation mode for the selected application is determined based on thecontext. In an embodiment, the operations modes may comprise managed andunmanaged modes. There may be multiple different managed modes, e.g.,based on different security levels of various users or sets ofcredentials provided by a user, different user roles identified by a setof credentials (e.g., manager versus staff employees), geographiclocations from which the device is operated, network locations,operational environment (e.g., a healthcare-related managed mode versusa financial industry managed mode), or based on any other contextualdetermination.

In an embodiment, the determined context may be compared to a storedpolicy in order to determine an operation mode. A mobile device, such asmobile device 302, may store one or more policies used to determine anoperation mode for an application. In an embodiment, the policies may bestored remotely, such as at policy manager 370, described above withreference to FIG. 3, or may be stored locally on the device. In anexample, a context may comprise a selected application configured toaccess a secure account, such as an email application configured toaccess a secure email account. This context may be compared to a storedpolicy. For instance, the stored policy may define that an emailapplication that is configured to access a secure email account is to berun as a managed application. The stored policy may further indicatethat the email application, when configured to access a personal accountof the device user, may operate in an unmanaged mode. Additionalcontexts and policies will be described with respect to FIGS. 38-42.

The method of FIG. 37 may proceed from step 3706 to step 3708, where theselected application is run in the determined operation mode. Forexample, the operation mode may be determined as unmanaged, or as one ofmultiple managed modes, and the selected application may be run in thedetermined mode.

In an embodiment, a managed operation mode may include running theapplication as a part of the managed partition 310 of mobile device 302,as described above with reference to FIG. 3. As such, the managedapplication may be run as secure native applications 314, secure remoteapplications 322 executed by a secure application launcher 318,virtualization applications 326 executed by a secure applicationlauncher 318, and the like.

In an embodiment, an application running in managed mode may access datastored in a secure data container 328 in the managed partition 310(physical, logical, or virtual) of the mobile device. The data stored inthe secure data container 328 may include data restricted to a specificsecure/managed application 330, shared among other secure applications,and the like. Data restricted to a secure application may include securegeneral data 334 and highly secure data 338. Different levels and typesof security features may be used to differentiate levels of secure data.In an embodiment, an application running in managed mode may save,modify, or delete data in secure data container 328. The data saved ormodified may be encrypted similar to other data stored in secure datacontainer 328.

In an embodiment, an application running in managed mode may connect toenterprise resources 304 and enterprise services 308 through virtualprivate network connections, as described about with reference to FIG.3. The virtual private network connections may be microVPNs, which arespecific to particular application, such as the selected application,particular devices, particular secured areas on the mobile device, andthe like. For example, wrapped applications in a secured area of thephone may access enterprise resources through an application specificVPN such that access to the VPN would be granted based on attributesassociated with the application, possibly in conjunction with user ordevice attribute information, and policy information.

In an embodiment, an application running in managed mode may encryptdata transmitted from the application. For example, an applicationrunning in managed mode may be communicating with a computing deviceover a network, and the data transmitted from the application to thedevice may be encrypted. In addition, the data communicated from thecomputing device to the application may also be encrypted, and theapplication running in managed mode may be configured to decrypt thereceived data.

In an embodiment, an application running in managed mode my access asecure portal. For example, an application may connect to a computingdevice over a network, for example, a microVPN, and may access a secureportal that might not be access by unsecured applications, such asapplications running in unmanaged mode.

In an embodiment, an unmanaged operation mode may include running theapplication as a part of the unmanaged partition 312 of mobile device302, as described above with reference to FIG. 3. In an unmanaged mode,the application may access data stored in an unsecured data container342 on the unmanaged partition 312 of the mobile device 302. The datastored in an unsecured data container may be personal data 344.

In an embodiment, where more than one managed mode is possible, anapplication running in a less secure managed mode may be run similar toan application running in the more secure managed mode, but might notinclude all aspects of the latter. For example, an application runningin a less secure managed mode may have the information transmitted fromthe application over a network encrypted, but the application might nothave access to secure data container 328, as described with reference toFIG. 3. In another example, an application running in the less securemanaged mode may have access to secure data container 328, but might notbe able to connect to enterprise resources 304 and enterprise services308 through virtual private network connections. Accordingly, dependingon the determined context, an application running in a less securemanaged mode may include aspects of an application running in the moresecure managed mode and aspects of an application running in unmanagedmode.

In FIGS. 38-42, flowcharts of example method steps for determining acontext and operation mode for an application are shown. In anembodiment, steps 3706 and 1608 of FIG. 37 may comprise the method stepsof any one or more of FIGS. 38-42. The method of FIG. 38 may begin atstep 3802, where an account to be accessed by a selected application isdetected. For example, a selected application may comprise an emailapplication and an email account that the email application isconfigured to access may be detected. In this example, the emailapplication may be able to access multiple email accounts, such as anenterprise email account and a personal email account, and the accountthat the email application is configured to access at the time ofrunning may be determined as the context account to be accessed.

The method of FIG. 38 may proceed from step 3802 to step 3804, where anaccount type of the account to be accessed may be determined. Theaccount type may comprise a context for the selected application. Forexample, a selected application may comprise an email application andthe email application may be configured to access an enterprise account.In another example, the email application may be configured to access apersonal account.

The method of FIG. 38 may proceed from step 3804 to step 3806, where anaccount type may be compared with an account type policy. For example, apolicy may define that an email application that is to access anenterprise account should run in managed mode and an email applicationthat is to access a personal account should run in unmanaged mode. Themethod of FIG. 38 may proceed from step 3806 to step 3808, where anoperation mode is determined based on the comparison.

The method of FIG. 39 may begin at step 3902, where a location for amobile device is determined. For example, a mobile device, such asmobile device 302, may implement the method of FIG. 39, and a locationfor the mobile device may be determined. The location may be determinedby GPS, signal triangulation, or any other suitable or otherwise knownmanner. The location may comprise a context for the selectedapplication.

The method of FIG. 39 may proceed from step 3902 to step 3904, where adetermined location may be compared with a location policy. For example,a policy may define that a selected application run in managed mode whenin a certain location, for example, on company premises. In anembodiment, a policy may define that a selected application run in aless secure managed mode when in a certain location, for example, whenthe determined location is inside the United States but off companypremises. For example, the less secure managed mode may encryptcommunication to and from the selected application, but might not allowaccess to enterprise resources, such as resources 304. In anotherembodiment, a policy may define that a selected application run inunmanaged mode when in a certain location, for example, when thedetermined location is outside the United States. The method of FIG. 39may proceed from step 3904 to step 3906, where an operation mode isdetermined based on the comparison.

Alternatively or in addition to physical location, a network locationmay also or instead be used to determine whether access is permitted.For example, network location may refer to whether a user is eitherinternal to a data center (or pre-approved Wifi access point), or isexternal to it. Appropriate access modes may be based on such adetermination.

The method of FIG. 40 may begin at step 4002, where it is monitoredwhether a predetermined application is running on a device. For example,a mobile device, such as mobile device 302, may implement the method ofFIG. 40, and the mobile device may be monitored to determine whether apredetermined application is running. The predetermined application maycomprise any application capable of running on the mobile device, such aclient agent 404 as described with reference to FIG. 4. The monitoredpredetermined application may comprise a context for the selectedapplication.

The method of FIG. 40 may proceed from step 4002 to step 4004, where amonitored application is compared against a policy. For example, apolicy may define that a selected application run in managed mode when apredetermined application, such as client agent 404, is running and thatthe selected application run in unmanaged mode when the predeterminedapplication is not running. The method of FIG. 40 may proceed from step4004 to step 4006, where an operation mode is determined based on thecomparison.

The method of FIG. 41 may begin at step 4102, one or more networkconnections are detected. For example, a mobile device, such as mobiledevice 302, may implement the method of FIG. 41, and the networkconnections that the mobile device makes may be detected. In an example,network connections may comprise a connection to a cellular network, aconnection to a WIFI network, or a connection to a Wireless Local AreaNetwork (WLAN), or the like. The one or more network connections maycomprise a context for the selected application.

The method of FIG. 41 may proceed from step 4102 to step 4104, wheredetected network connections are compared against a network connectionpolicy. For example, a policy may define that a selected application runin managed mode when a mobile device is connected to an internalnetwork, such as a WLAN internal to a company, and that the selectedapplication run in unmanaged mode when the mobile device is onlyconnected to a wireless network, such as cellular network or WIFInetwork. The method of FIG. 41 may proceed from step 4104 to step 4106,where an operation mode is determined based on the comparison.

The method of FIG. 42 may begin at step 4202, where one or more settingsfor a mobile device are detected. For example, a mobile device, such asmobile device 302, may implement the method of FIG. 42, and one or moresettings for the mobile device may be detected. In an example, it may bedetected whether the mobile device has a lock screen, such as a PINrequired for using the mobile device, or it may be detected whether themobile device is jailbroken/rooted, e.g., has received after-marketmodifications. The one or more settings may comprise a context for theselected application.

The method of FIG. 42 may proceed from step 4202 to step 4202, wheredetected settings are compared against a settings policy. For example, apolicy may define that a selected application might not run in managedmode if the mobile device does not have a lock screen or if the mobiledevice is jailbroken/rooted. The method of FIG. 42 may proceed from step4206 to step 4206, where an operation mode is determined based on thecomparison. In an embodiment, when running the selected application inthe determined mode, an indicator may be displayed on the mobile devicethat informs a user of certain policies, such as a requirement for amobile device to have a lock screen before the mobile device is allowedto run the selected application in managed mode. FIGS. 38-42 describe aplurality of contexts, and any other suitable context and correspondingpolicy may be implemented.

In an embodiment, one or more of the contexts described in FIGS. 38-42may be combined and these contexts may be compared against a policy forthe selected application. For example, contexts for a selectedapplication may comprise an account type to be accessed as an enterpriseemail account and a detected network connection as a cellular network.In this example, the policy may define that when an enterprise accountis attempted to be accessed over a cellular network, the selectedapplication should be run in managed mode. The policy may be defined inthis way because the selected application may encrypt the communicationwith the enterprise email account, and therefore the risk of sendingsecure traffic over a cellular network may be mitigated.

In another example, contexts for a selected application may comprise adetermined location outside of the United States and a networkconnection with a WLAN internal to a company. A policy may define that aselected application is to run in managed mode when a determinedlocation is outside the United States and a network connection is with aWLAN internal to a company. The policy may be defined in this waybecause a network connection with a WLAN internal to a company mitigatesthe risk associated with secure communications outside of the UnitedStates.

In an embodiment, the one or more contexts as described in FIGS. 38-42may include a priority. For example, a context for a selectedapplication may comprise a mobile device setting as jailbroken or rootedand a policy may define that a selected application is to run only inunmanaged mode when a context indicates a jailbroken/rooted mobiledevice, regardless of what other contexts indicate. Accordingly, ajailbroken/rooted mobile device will have a selected application run inunmanaged mode even when the mobile device is connected to a WLANinternal to a company or if the selected application is attempting toaccess an enterprise account.

In an embodiment, a policy may indicate that a selected application isto be run in a less secure managed mode based on a plurality of contextsas described in FIGS. 38-42. For example, contexts for a selectedapplication may comprise an account type to be accessed as an enterpriseemail account and a detected network connection as a cellular network.In this example, the policy may define that when an enterprise accountis attempted to be accessed over a cellular network, the selectedapplication should be run in the less secure managed mode. The lesssecure managed mode may encrypt communication to and from the selectedapplication, but might not allow access to enterprise resources, such asresources 304. The policy may be defined in this way because theencrypted communication with the enterprise email account may be a lowrisk communication, and allowing access to enterprise resources may be ahigh risk communication.

In FIG. 43, a flowchart of example method steps for switching anoperation mode for an application is shown. For example, the methodsteps of FIG. 43 may follow the method steps of FIG. 37. The method ofFIG. 43 may begin at step 4302, where one or more contexts may bemonitored while a selected application is running. In an embodiment, oneor more of the contexts described with reference to FIGS. 38-42 may bemonitored. For example, a mobile device running a selected applicationmay be connected to a cellular network and while the selectedapplication is running, the mobile device may make a new networkconnection with a WLAN internal to a company.

The method of FIG. 43 may proceed from step 4302 to step 4304, where achange in an operation mode for a selected application is detected basedon the monitoring. Stated differently, the mobile device may detect achange in information that formed the basis for selecting a particularoperational mode. For example, a selected application may be running inunmanaged mode, and once a mobile application running the selectedapplication connects to a WLAN internal to a company, a policy maydefine that the operation mode for the selected application shouldswitch to managed mode. The method of FIG. 43 may proceed from step 4304to step 4306, where the operation mode for the selected application isswitched.

FIG. 55 shows an illustrative method for choosing policy file(s) basedon the operating mode of an app on a mobile device. Initially, a managedapplication may be received and/or installed in step 5501 on a mobileelectronic device, as described herein, where the managed app is capableof executing in at least two different operating modes. In step 5503 thedevice may separately and/or distinctly receive one or more policy filesdefining one or more operational and/or behavioral limitations of themanaged app, e.g., based on one or more features discussed above. Whilethe policy file(s) may be optionally received as separate files, thepolicy files may be received as part of a same communication orinstallation process as the managed app. The device may receivedifferent policy files for each operating mode, or may receive policyfiles only for one operating mode. That is, an unmanaged mode might notbe associated with any policy files.

In step 5505 the mobile device determines an operating mode of themanaged app, e.g., whether the managed app is executing in managed orunmanaged mode. In step 5507 the device may select one or more policyfiles (or zero policy files, e.g., in an unmanaged mode) to apply to thecurrent operating mode of the managed app. Various examples of suchpolicy files and multi-mode features and processes that may berestricted/enforced are discussed above.

11. ENTERPRISE APPLICATION APP STORE

As discussed above, with reference back to FIG. 3, an enterprisemobility technical architecture 300 may include an application store378. The application store 378 may include unwrapped applications 380,pre-wrapped applications 382, and the like. Applications may bepopulated in the application store 378 from the application controller374. The application store 378 may be accessed by the mobile device 302through the access gateway 360, through the public Internet 348, or thelike. The application store may be provided with an intuitive and easyto use user interface. The application store 378 may provide access to asoftware development kit 384. The software development kit 384 mayprovide a user the capability to secure applications selected by theuser by wrapping the application as described previously in thisdescription. An application that has been wrapped using the softwaredevelopment kit 384 may then be made available to the mobile device 302by populating it in the application store 378 using the applicationcontroller 374.

The enterprise mobility technical architecture 300 may include amanagement and analytics capability. The management and analyticscapability may provide information related to how applications aredownloaded and/or used, how often applications are downloaded and/orused, and the like. How applications are used may include which devicesdownload which applications, which applications access which data, andthe like. How often applications are used may include how often anapplication has been downloaded, how many times a specific set of datahas been accessed by an application, how often the application islaunched, shared, interfaced, referenced, called, and the like.

In some embodiments, the one or more controls that are included in themobile service management interface (e.g., the mobile service managementinterface provided in step 620) may be further configured to allow theadministrative user to define different policies for different users ofthe one or more applications. For example, the one or more controls thatare included in the mobile service management interface may beconfigured to allow the administrative user to define a first policy fora first user or group of users with respect to a particular application,and further configured to allow the administrative user to define asecond policy for a second user or group of users with respect to thesame application, where the second policy is different from the firstpolicy and the second user or group of users is different from the firstuser or group of users.

In one or more arrangements, the one or more controls that are includedin the EMM or enterprise app store interface may be further configuredto allow an administrative user to define different policies fordifferent user roles and/or applications on the application store. Forexample, using such controls, the administrative user may define, withrespect to a particular application that may be available in theenterprise application store, a first policy for a first user or groupof users having a first role within an enterprise (e.g., informationsecurity) and a second policy for a second user or group of users havinga second role within the enterprise (e.g., sales), where the secondpolicy is different from the first policy (e.g., in terms of thefunctions that are enabled and/or disabled in the application, thefunctions that are enabled and/or disabled on the device while theapplication is running, the enterprise resources and/or other resourcesthat can and/or cannot be accessed by the application and/or while theapplication is running, etc.).

In some embodiments, the EMM or store interface may be provided inresponse to receiving one or more applications at the enterpriseapplication store. For example, after an administrative user uploadsand/or otherwise provides a particular application to the enterpriseapplication store, the enterprise application store may provide themobile service management interface (which may, e.g., be configured toallow the administrative user to define one or more policies for theapplication that has just been uploaded) responsive to receiving theapplication. Using these features, an administrative user of theenterprise application store may, for instance, configure an applicationthat he or she is uploading into and/or otherwise making available inthe enterprise application store for various non-administrative users ofthe enterprise application store. For instance, the administrative usermay be able to use the mobile service management interface to initiallydefine policies for an application that has just been uploaded to and/orotherwise added to the enterprise application store.

In some instances, after providing the application store interface, apolicy change for an application may be received via the applicationstore interface. For example, in some instances, the enterpriseapplication store may receive a policy change for a particularapplication. Such a policy change may, for instance, be received as userinput provided by the administrative user via the application storeinterface.

Based on receiving such a policy change, information associated with thepolicy change may automatically be provided to one or more mobiledevices that have already downloaded the application from theapplication store. For example the enterprise application store mayprovide information specifying details of the policy change to one ormore applications and/or devices that may be affected by the policychange. In some instances, before providing this information to affectedapplications and/or devices, the enterprise application store mayidentify what applications and/or devices are affected by the policychange based on download history information for various applicationsand users, update and/or version history information for variousapplications and users, on-device monitoring information for variousapplications and users, and policy information for various applicationsand users (which may, e.g., specify for particular applications and/orparticular users what policies are currently in place, what policieshave been previously applied, etc.).

In some embodiments, after validating the authentication credentials ofthe administrative user, a new application may be received at theapplication store from the administrative user. For example, aftervalidating the authentication credentials of the administrative user,the enterprise application store may receive a new application that isbeing uploaded to (and/or has just been uploaded to) the enterpriseapplication store by the administrative user (and/or by one or morecomputing devices being used by the administrative user).

After receiving such a new application from the administrative user(and/or responsive to receiving the new application from theadministrative user), the application store may prompt theadministrative user to define one or more policies to be applied to thenew application. For example, in prompting the administrative user todefine such policies, the enterprise application store may identify oneor more relevant policies for the new application. The relevant policiesmay, for instance, include policies that can be and/or should be appliedto the new application (e.g., based on the nature of the policies, basedon the nature of the application, based on one or more default policiesused by the enterprise and/or other organization that is deployingand/or otherwise providing the enterprise application store, based onrecommendation information provided by other administrative users,etc.). Then, after identifying one or more relevant policies for the newapplication, the enterprise application store may, for instance, updatethe application store interface to include at least one controlconfigured to allow the administrative user to manage the one or moreidentified policies. For example, the enterprise application store mayupdate the application store interface to include one or more controlsthat enable the administrative user to enable and/or disable the one ormore policies that were identified as being relevant, as well as setand/or modify various properties and/or settings that may be used indefining and/or enforcing these policies on various devices.

After prompting the administrative user to define one or more policiesto be applied to the new application (and/or based on receiving inputand/or other information from the administrative user in response to theprompt), the application store may receive at least one policy to beapplied to the new application from the administrative user. Forexample, the enterprise application store may receive one or moreselections and/or other input provided by the administrative user viathe updated application store interface discussed in the example above.In this way, the administrative user may, for example, be able to defineone or more policies that are to be applied to a new application thatthe administrative user has added to the application store. In addition,the one or more policies that are defined by the administrative usermay, for example, be applied to the new application if and/or when theapplication is provided to and/or executed by one or more recipientdevices (e.g., one or more mobile devices used by non-administrativeusers).

FIG. 47 depicts a flowchart that illustrates a method of providingpolicy updates to managed applications using an enterprise applicationstore in accordance with one or more illustrative aspects discussedherein. In one or more embodiments, the method illustrated in FIG. 47and/or one or more steps thereof may be performed by a computing device(e.g., any device described herein). In other embodiments, the methodillustrated in FIG. 47 and/or one or more steps thereof may be embodiedin computer-executable instructions that are stored in acomputer-readable medium, such as a non-transitory computer-readablememory.

As seen in FIG. 47, the method may begin at step 4705 in which a requestfor updated policy information for at least one application may bereceived at an enterprise application store from a policy agent. Forexample, in step 4705, an enterprise application store, similar to theenterprise application store discussed in the examples above, mayreceive a request for updated policy information. The request may bemade in connection with policies that may be applied to (or may beconfigured to be applied to) a particular application and may, forinstance, be received from a policy agent that is resident on, beingexecuted on, and/or is otherwise provided by a user computing device(e.g., a mobile device, such as a smart phone, a tablet computer, etc.).

In some instances, the request for updated policy information may bereceived (e.g., by the enterprise application store in step 805) uponexecution of a wrapped application. For example, the enterpriseapplication store may receive the request for updated policy informationafter a user computing device begins executing a wrapped application.Such a wrapped application may, for instance, include an enterpriseapplication, as well as an application wrapper, that may be configuredto enforce one or more policies with respect to the enterpriseapplication and/or the device upon which the wrapped application isbeing executed. In addition, such an application wrapper may, forinstance, implement one or more aspects of the application managementframework 414 discussed above.

In some instances, the policy agent (e.g., from which the request forupdated policy information is received in step 4705) may be a EMM policyenforcement agent (e.g., on a user computing device). Such a mobiledevice management policy enforcement agent may, for instance, be aseparate program, process, or service that is executed on (or configuredto be executed on) a user computing device and is further configured tomonitor and enforce various policies with respect to variousapplications and the device itself.

In other instances, the policy agent (e.g., from which the request forupdated policy information is received in step 4705) may be anapplication wrapper for a particular application. For example, thepolicy agent may be an application wrapper for the particularapplication for which the request for updated policy information isreceived in step 4705. As discussed above, such an application wrappermay be configured to enforce one or more policies with respect to theapplication and, in some instances, may implement one or more aspects ofthe application management framework 414 discussed above.

Based on receiving the request for updated policy information (e.g., instep 4705), it may be determined, in step 4710, whether one or morepolicies for the at least one application have been updated. Forexample, in step 4710, the enterprise application store may determineone or more policies for the one or more applications (e.g., the one ormore applications that are the subject of the request received in step4705) have been updated. The one or more policies for a particularapplication may, for instance, be updated although the applicationitself has not been updated (e.g., the policies can be modifiedindependently of the application itself and/or an application wrapperthat may be used to wrap the application). In one or more arrangements,the enterprise application store may determine whether policies for anapplication have been updated based on policy information that is storedby, maintained by, and/or accessible to the enterprise applicationstore. In some instances, such policy information may be created,accessed, modified, and/or stored by the enterprise application storebased on user input and/or other information received from anadministrative user of the enterprise application store, such asinformation received from an administrative user of the enterpriseapplication store via a application store interface, as discussed above.

Continuing to refer to FIG. 47, if it is determined, in step 4710, thatone or more policies for the at least one application have not beenupdated, then in step 4715, the policy agent may be notified thatupdates are not available. For example, in step 4715, the enterpriseapplication store may notify the policy agent that updates are notavailable. For instance, in step 4715, the enterprise application storemay send one or more messages to the user computing device (which may,e.g., have sent the request received in step 4705) to inform the usercomputing device and/or the policy agent being executed thereon thatpolicy updates are not available and/or that the user computing deviceshould continue to use and/or enforce one or more policies that thepolicy agent has previously obtained from the enterprise applicationstore.

Alternatively, if it is determined, in step 4710, that one or morepolicies for the at least one application have been updated, then instep 4720, at least one policy update may be provided to the policyagent. For example, in step 4720, the enterprise application store maysend one or more messages to the user computing device (which may, e.g.,have sent the request received in step 4705) to inform the usercomputing device and/or the policy agent being executed thereon that oneor more policy updates and/or available. In addition, the one or moremessages sent by the enterprise application store to the policy agentmay, for instance, include information about the new and/or modifiedpolicies, where such information is configured to cause the policy agentto implement and/or enforce the new and/or modified policies (e.g., withrespect to the particular applications for which policy changes haveoccurred and/or with respect to the device itself). As in the examplesdiscussed above, the one or more policies may be configured to enableand/or disable certain features of the one or more applications, enableand/or disable certain features of the device, enable and/or disableaccess to certain resources, and/or provide other functionalities and/orlimitations, and the information provided (e.g., as a policy update tothe policy agent in step 4720) may reflect any and/or all changes madeto these and/or other types of policies.

FIG. 48 depicts another flowchart that illustrates a method of providingpolicy updates to managed applications using an enterprise applicationstore in accordance with one or more illustrative aspects discussedherein. In one or more embodiments, the method illustrated in FIG. 48and/or one or more steps thereof may be performed by a computing deviceas described herein. In other embodiments, the method illustrated inFIG. 48 and/or one or more steps thereof may be embodied incomputer-executable instructions that are stored in a computer-readablemedium, such as a non-transitory computer-readable memory. Additionallyor alternatively, the method illustrated in FIG. 48 may, in someinstances, be combined with the method illustrated in FIG. 47. Forexample, the method illustrated in FIG. 48 may be performed by anenterprise application store before and/or after performing the methodillustrated in FIG. 47.

As seen in FIG. 48, the method may begin in step 4805, in which a policychange for an application may be received at the enterprise applicationstore. For example, in step 4805, the enterprise application store mayreceive a policy change for a particular application from anadministrative user of the enterprise application store. Such a policychange may, for instance, be received via a application store interface,as discussed above.

Continuing to refer to FIG. 48, in instances in which a policy changefor an application is received by the enterprise application store, buta request for updated policy information has not yet been received, atleast with respect to the particular application from certain devices,the enterprise application store may determine to proactively providethe policy update to the affected devices. Thus, based on receiving apolicy change (e.g., in step 4805), it may be determined, in step 4810,that the application (i.e., the application for which a policy changewas received in step 4805) is present on one or more devices. Forexample, in step 4810, the enterprise application store may determinethat the application has been installed on, has been downloaded by,and/or is otherwise present on one or more particular devices. In someinstances, the application store may determine that the application hasbeen installed on, has been downloaded by, and/or is otherwise presenton one or more particular devices based on download history informationfor various applications and users, update and/or version historyinformation for various applications and users, and/or on-devicemonitoring information for various applications and users. In one ormore arrangements, the download history information for variousapplications and users may include user-keyed application downloadrecords that indicate, for each user, the versions and names of anyand/or all applications that have been downloaded by the particular userfrom the enterprise application store, as well as identifyinginformation for the particular devices onto which such applications weredownloaded.

Based on determining that the application is present on one or moredevices (e.g., in step 4810), information associated with the policychange may be provided to the one or more devices in step 4815. Forexample, in step 4815, the enterprise application store may provideinformation about the policy change to one or more affected devices(e.g., the one or more devices on which the application was determinedto be present in step 4810). For instance, in step 4815, the enterpriseapplication store may formulate and send one or more messages to thedevices identified in step 4810, where the one or more messages includeinformation about the new and/or modified policies, similar to how apolicy update may be provided in step 4720.

Using one or more of the above enterprise application store features, asystem may be configured to provide an enterprise application app storeinformation about a mobile client device and usable by the enterpriseapplication app store to present one or more applications downloadableby the mobile client device, or permissible for download by that devicebased on the policy information. For example, the policy files mightidentify the mobile client device as capable of executing managedapplications according to corresponding policy files. In response, theapp store might expose for download a list of availablepolicy-manageable applications. The client device can then download anapplication, as needed.

In another example, the set of policy files might identify theelectronic mobile device as being capable of executing applicationsexecutable in multiple execution modes (e.g., unmanaged, managed mode 1,managed mode 2, etc.). In response the app store might expose fordownload a list of available managed applications each executable inmultiple execution modes. The mobile client can then download any ofthose applications, as needed.

In yet another example, the set of policy files might identify theelectronic mobile device as being enrolled in an enterprise mobilitymanagement (EMM) infrastructure. In response, the app store might exposefor download a list of available enterprise applications. The mobileclient can then download any of those applications, as needed.

12. MOBILE FEATURE INTEROPERABILITY

Any of the above features, whether described alone or as part of anotherfeature, may be used with any one or more of the other featuresdescribed herein.

For example, policy managed applications can be adapted to provide asecure cut & paste data sharing feature, restricted data sharingfeatures, and/or policy based data sharing features. Similarly, policymanaged applications are usable with EMM and MRM services andinfrastructures, either with our without any one or more of theaforementioned data sharing features. In one illustrative example, apolicy managed app may restrict access to a secure clipboard based onwhether or not the managed app is enrolled in a MRM system. If themanaged app is enrolled in the MRM system, the managed app may haveaccess to a first secure clipboard. However, if the managed app is notenrolled in the MRM system, then the managed app may have access to adifferent second secure clipboard, or only to a general clipboard.

Similarly, policy managed applications are usable with applicationspecific policies, e.g., secure Internet applications, secure PIMapplications, secure client agent applications, etc., either with orwithout any one or more of the aforementioned data sharing and/orEMM/MRM services. In one illustrative example, a policy managed securebrowser app may restrict execution of HTML5 or other browser-basedexecution environments based on whether or not the device is enrolled inthe MRM, based on a geographic location of the device, a time of day, orthe like. In another example, the policy managed secure browser app maybe restricted from accessing a secure clipboard while executing anotherprogram in HTML5, FLASH, or other execution environment.

Similarly, policy managed applications are usable with any one or morenetwork and data access features such as micro VPNs, tunnels, securecontainers, single-sign on techniques, and/or identity managementtechniques, either with or without any one or more of the aforementioneddata sharing features, EMM/MRM features, and/or application specificpolicy features. In one illustrative example, a policy managed app maybe restricted from accessing an enterprise secure storage area exceptthrough a secure micro VPN or tunnel. In another example, a policymanaged app may be restricted from using single-sign on except when themobile device on which the managed app is executing is enrolled in theMRM system, and when the managed app is a predefined specific type ofapp.

Similarly, policy managed applications are usable with any one or moredynamic device cloud features, either with or without any one or more ofthe aforementioned data sharing features, EMM/MRM features, applicationspecific policy features, and/or network and data access features. Inone illustrative example, a policy managed app may be restricted fromtransferring a process to another device unless both devices areenrolled in the MRM system, and both devices are communicating through asecure channel, e.g., micro VPN, tunnel, etc.

Similarly, policy managed applications are usable with one or morefeatures operable with applications capable of execution in multipleoperation modes, either with or without any one or more of theaforementioned data sharing features, EMM/MRM features, applicationspecific policy features, network and data access features, and/ordynamic device cloud features. In one illustrative example, a policymanaged app may be restricted from accessing an enterprise securestorage area except through a secure micro VPN or tunnel, and only whenthe managed app is operating in a predefined operating mode frommultiple possible operating modes (e.g., in a managed mode). In anotherexample, a policy managed app may be restricted from using single-signon except when the mobile device on which the managed app is executingis enrolled in the MRM system and when the managed app is operating in apredefined mode.

Similarly, policy managed applications are usable with one or moreenterprise application app store features, either with or without anyone or more of the aforementioned data sharing features, EMM/MRMfeatures, application specific policy features, network and data accessfeatures, dynamic device cloud features, and/or multiple operation modefeatures.

It is intended that any feature described herein may be combined and/orused with any other feature described herein. The above recitedcombinations are not meant to be limiting, but rather are illustrativeof what can be accomplished using the individual tools recited above.Any combination of features will inherently provide one or more specificadvantages not otherwise capable, whether two, three, four, five, ormore features are combined together. The above features should thereforebe regarded as individual tools that may be selectively combined in anydesired manner to complete a desired task or operational design, whereone or more tools in and of themselves are unique, yet combinations oftools yield even further unexpected results and advantages.

13. CONCLUSION

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter herein is not necessarily limited to thespecific features or acts described above. Rather, the specific featuresand acts described above are described as illustrative implementations,embodiments, and aspects of the appended claims.

What is claimed is:
 1. A method of managing applications on a mobiledevice, comprising: executing, on the mobile device, a client agentapplication configured to enforce one or more policy files of a mobiledevice management system, wherein each policy file defines one or moreaccess controls enforced by the mobile device management system when oneor more applications are executing locally on the mobile device, andwherein the client agent application is further configured to wirelesslycommunicate with one or more applications executing on a remotecomputing device and presented on a display of the mobile device.
 2. Themethod of claim 1, wherein the client agent is configured to facilitatethe one or more remote applications by: receiving input from a userintended for a particular remote application; passing the user input tothe particular remote application; receiving data from the particularremote application responsive to the user input; and presenting the databy the client agent application on the display of the mobile device. 3.The method of claim 2, wherein receiving data from the particular remoteapplication comprises receiving the data via a remote presentationprotocol, and wherein the received data comprises output from the remoteapplication to update a graphical user interface presented by the clientagent on the display of the mobile device.
 4. The method of claim 1,further comprising: applying, by the client agent application, a firstset of one or more policy files when an application is executing locallyon the mobile device; and applying, by the client agent application, asecond set of one or more policy files when a remote application ispresented on the mobile device.
 5. The method of claim 1, furthercomprising automatically determining, by the client agent application,whether to initiate execution of a user-requested application locally orremotely, based on one or more policy files identifying whether or noteach of one or more applications comprising the user-requestedapplication is permitted to run locally on the mobile device.
 6. Themethod of claim 1, further comprising: receiving first user inputrequesting execution of a first application on the mobile device,wherein the first application is a local application; executing,responsive to the first user input, the first application according to afirst set of policy files; receiving second user input requestingexecution of a second application on the mobile device, wherein thesecond application is a local application; executing, responsive to thesecond user input, the second application according to a second set ofpolicy files; receiving third user input requesting execution of a thirdapplication on the mobile device, wherein the third application is aremote application; responsive to the third user input, initiatingremote execution of the third application on the remote computing deviceaccording to a third set of policy files.
 7. The method of claim 1,further comprising: receiving one or more updated policy files replacinga corresponding one or more existing policy files stored on the mobiledevice; and updating the access controls enforced by the mobile devicemanagement system according to the one or more updated policy files. 8.The method of claim 7, wherein updating the access controls comprisesautomatically removing from the mobile device a local application. 9.The method of claim 7, wherein updating the access controls comprisesautomatically deleting user data associated with the removed localapplication.
 10. A mobile device comprising a processor configured toexecute, based on instructions stored in a memory, a client agentapplication configured to enforce one or more policy files of a mobiledevice management system, wherein each policy file defines one or moreaccess controls enforced by the mobile device management system when oneor more applications are executing locally on the mobile device, andwherein the client agent application is further configured to wirelesslycommunicate with one or more applications executing on a remotecomputing device and presented on a display of the mobile device. 11.One or more non-transitory computer readable media storing computerexecutable instructions that, when executed, cause a system to manageapplications on a mobile device by: executing, on the mobile device, aclient agent application configured to enforce one or more policy filesof a mobile device management system, wherein each policy file definesone or more access controls enforced by the mobile device managementsystem when one or more applications are executing locally on the mobiledevice, and wherein the client agent application is further configuredto wirelessly communicate with one or more applications executing on aremote computing device and presented on a display of the mobile device.12. The computer readable media of claim 11, wherein the client agent isconfigured to facilitate the one or more remote applications by:receiving input from a user intended for a particular remoteapplication; passing the user input to the particular remoteapplication; receiving data from the particular remote applicationresponsive to the user input; and presenting the data for display by theclient agent application.
 13. The computer readable media of claim 12,wherein receiving data from the particular remote application comprisesreceiving the data via a remote presentation protocol, and wherein thereceived data comprises output from the remote application to update agraphical user interface presented by the client agent on the display ofthe mobile device.
 14. The computer readable media of claim 11, whereinthe instructions further cause the system to manage applications on amobile device by: applying, by the client agent application, a first setof one or more policy files when an application is executing locally onthe mobile device; and applying, by the client agent application, asecond set of one or more policy files when a remote application ispresented on the mobile device.
 15. The computer readable media of claim11, wherein the instructions further cause the system to manageapplications on a mobile device by automatically determining, by theclient agent application, whether to initiate execution of auser-requested application locally or remotely, on an application byapplication basis, based on one or more policy files identifying whetheror not each of one or more applications comprising the user-requestedapplication is permitted to run locally on the mobile device.
 16. Thecomputer readable media of claim 11, wherein the instructions furthercause the system to manage applications on a mobile device by: receivingfirst user input requesting execution of a first application on themobile device, wherein the first application is a local application;executing, responsive to the first user input, the first applicationaccording to a first set of policy files; receiving second user inputrequesting execution of a second application on the mobile device,wherein the second application is a local application; executing,responsive to the second user input, the second application according toa second set of policy files; receiving third user input requestingexecution of a third application on the mobile device, wherein the thirdapplication is a remote application; responsive to the third user input,initiating remote execution of the third application on the remotecomputing device according to a third set of policy files.
 17. Thecomputer readable media of claim 11, wherein the instructions furthercause the system to manage applications on a mobile device by: receivingone or more updated policy files replacing a corresponding one or moreexisting policy files stored on the mobile device; and updating theaccess controls enforced by the mobile device management systemaccording to the one or more updated policy files.
 18. The computerreadable media of claim 17, wherein updating the access controlscomprises automatically removing from the mobile device a localapplication.
 19. The computer readable media of claim 17, whereinupdating the access controls comprises automatically deleting user dataassociated with the removed local application.
 20. The mobile device ofclaim 10, wherein the instructions further cause the mobile device tomanage applications by: applying, by the client agent application, afirst set of one or more policy files when an application is executinglocally on the mobile device; and applying, by the client agentapplication, a second set of one or more policy files when a remoteapplication is presented on the mobile device.